https://blogs.networld.co.jp/entry/2026/03/30/143920

みなさんこんにちは。ネットワールドでAWS担当のセールスをしている福住です。ストレージ探偵ずーみんとしても活動していますが、今回はAWSのお話です。

この記事のサマリー

やったこと: AWS Partner Central ↔ Kintoneの双方向リアルタイム連携をバイブコーディングで構築
期間: 約1週間（プログラミング未経験者が一人で実装）
コスト: AIツール利用料のみ（従来の外注開発なら12週間・数百万円規模）
技術スタック: Kintone Webhook / API Gateway / Lambda（Python） / EventBridge / Partner Central Selling API
この記事が役立つ人: AWSパートナーでACEでの案件登録に難儀している方、Partner Central Selling APIを触ろうとしている方、バイブコーディングに興味がある方

はじめに

わたしはAWS担当セールスとして、パートナー様のリクルートやビジネス推進を担当しています。SEやエンジニア経験はまったくなく、プログラミングにいたっては完全なシロウトです。日々の業務では、AWS Partner CentralのACEへの案件登録も実施していますが、めんどうな作業なのでいつも苦労しています。

📝 ACEとは

APN Customer Engagements (ACE) Programのことでいわゆる案件登録のことです。AWSパートナーはこのACEに多数の案件を登録すること=案件を創出することがとても重要なミッションになります。

そんなおり、AWSさんからCRM統合の仕組みをご紹介いただきました。AWSパートナーは自社で利用しているSFA/CRMに案件登録をして、さらにACEにも案件登録をしなければなりません。この「二重入力」が多くのAWSパートナーの課題でした。ただでさえめんどくさい入力作業を二回もするのは苦痛ですよね。

AWSさんもこの課題は理解していて、Salesforce用のプラグインを開発したり、その他CRM/SFAと連携用のAPIを用意してくれています。

docs.aws.amazon.com

そこでわたしたちがチームで利用しているKintoneの案件管理アプリとACEをリアルタイム連携させてみることにしました。AWSさんからは開発作業に12週間程度かかると説明を受けていましたが、バイブコーディングによりシロウト営業一人、一週間でこの連携を実現できました。

本記事では、AWSパートナーの皆さまに向けて、開発の過程とハマりポイント、そしてバイブコーディングのコツを共有します。

作ったもの

システム概要

AWS Partner CentralとKintoneの案件情報を 双方向リアルタイム で同期するシステムです。

Kintone → AWS方向: Kintoneでレコードを追加・編集すると、Webhookが発火し、API Gateway → Lambda経由でPartner CentralにCreateOpportunity/UpdateOpportunityが実行されます。さらに、オポチュニティの自動提出（AWSレビューへの送信）まで一連の処理として実装しています。

AWS → Kintone方向: Partner Central側でオポチュニティが変更されると、Amazon EventBridgeがイベントを検知し、Lambda経由でKintoneのレコードが更新されます。AWSのレビュー承認・却下などのステータス変化もKintoneにリアルタイム反映されます。

同期対象

案件名、顧客会社名、業種、ユースケース、商談ステージ、配信モデルなど 17項目 を双方向で同期。AWSレビューステータスなどAWS側が管理する項目は、AWS→Kintone方向のみの読み取り専用フィールドとして設計しました。

技術構成

コンポーネント	技術
Kintone→AWS	Kintone Webhook → API Gateway → Lambda（Python） → Partner Central Selling API
AWS→Kintone	Partner Central → EventBridge → Lambda（Python） → Kintone REST API
認証	AWS側: SigV4（IAMロール）、Kintone側: APIトークン
リージョン	Lambda①: ap-northeast-1、Lambda②+EventBridge: us-east-1

従来なら12週間かかる理由

このシステムを従来の開発プロセスで構築しようとすると、12週間程度の開発期間がガイドされています。

1. Partner Central Selling APIの情報が極めて少ない

AWS Partner Central Selling APIは比較的新しいサービスで、日本語のドキュメントやブログ記事がほぼ存在しません。公式ドキュメント（英語）を読み解きながら、パラメータの構造を一つずつ確認していく必要があります。

さらに厄介なのが、Partner Centralの画面上の項目名とAPI上のパラメータ名が一致しないケースが多いことです。例えば画面上で「ソリューション」と表示されている項目は、APIではProject.SolutionsではなくRelatedEntityIdentifiers.Solutionsという全く異なるパスにあります。

2. 日本語⇔英語の変換マップが膨大

Partner Central APIは英語のEnum値しか受け付けません。Kintoneの日本語UIとの間で、業種27項目、ユースケース38項目、支援内容9項目など、合計80以上の値変換マップを正確に作成する必要があります。1つでもスペルを間違えるとValidationExceptionです。

3. 双方向同期の「無限ループ」問題

双方向同期で最も難しいのが無限ループの防止です。

Kintone更新 → Webhook → AWS更新 → EventBridge → Kintone更新 → Webhook → ...

この問題は設計段階で認識していましたが、最初に実装したフラグ方式がうまくいかず、2回の設計変更を経て「更新者チェック方式」にたどり着きました。この試行錯誤だけで従来なら数日を要するところです。

1週間の開発タイムライン

Day 1〜2: 設計フェーズ

AIにAWSから提供されていたドキュメントを読んでもらい「AWS Partner CentralとKintoneを双方向で連携したいけどできる？」と聞いてみたところ、「できるよー」と言ってくれたので開発してみることにしました。

docs.aws.amazon.com

www.postman.com※Postmanは結果的に利用しませんでした。

次にAIがやってくれたのは、設計書のたたき台作成です。アーキテクチャ構成、フィールドマッピング表、値変換表、AWSリソース設定、注意事項まで含む包括的な設計書を、対話しながら数時間で完成させました。

この設計書が以降の開発で「AIの記憶」として機能します。セッションをまたいでもこの設計書を読み込ませれば、AIは文脈を理解した上でコードを書いてくれます。

Kintone側はKintone MCPサーバーを構築済みだったので特に何もしていません。

cybozu.dev

Day 3〜4: Kintone→AWS方向の実装とテスト

Lambda関数のコードをAIに生成させ、AWS環境にデプロイしてテスト。ここで多くのエラーに遭遇しましたが、CloudWatchのエラーログをそのままAIに貼り付けるだけで原因を特定し、修正コードを提示してくれました。

主なエラーと解決：

ParamValidationError: パラメータ名の誤り → AIが正しいAPI仕様を調査して修正
ValidationException: 日本語値をそのまま送信 → 英語変換マップを自動生成
無限ループ発生: フラグ方式の限界 → 更新者チェック方式に設計変更

Day 5〜6: AWS→Kintone方向の実装とテスト

EventBridgeの設定とLambda関数の実装。恥ずかしながらEventBridgeの設定方法がよくわかりませんでした。AIの指示と実際のGUI画面が合致せず、設定が正しくできたの自信がもてませんでした。そこでAWS側設定はCLIで出力してもらいCloudShellにコピペすることで解決できました。また、ここでも「エラーログを貼る→AIが修正」のサイクルを繰り返しました。

最もAIが苦労していたのは、Kintone APIの CB_IJ01: 不正なJSON文字列です エラーです。JSON構文は正しいのにエラーが出る。原因がわからず、AIの提案で「最小ペイロードから1フィールドずつ追加」するデバッグ手法を試し、「配信モデル」フィールドが配列ではなく文字列を期待していることを特定しました。

ポイント: AIは「最小構成で切り分ける」というデバッグの基本を忠実に実行してくれます。

Day 7: 仕上げ

残りのフィールド実装（ソリューション名の動的解決、月間収益）、設計書の最終更新、運用ドキュメント作成を完了。

運用開始後: 追加修正フェーズ

「動いた！」と思ってからが本番でした。実際の案件データで使い始めると、さらに5つのバグが見つかりました。いずれも「CloudWatchログを貼る→AIが解析→修正コード提示」のサイクルで解決しています。

1週間で完成できたもう一つの理由

バイブコーディングの威力が大きかったのは事実ですが、振り返るとそれ以外の要因も短期完成に大きく貢献していました。

1. KintoneアプリがもともとACE連携を前提とした設計だった

実はこのKintone案件管理アプリ、Partner Central連携を始める以前から、ACE（APN Customer Engagements）ポータルへの入力を意識して設計していました。ACE側の必須項目に合わせてKintoneのフィールドを揃えていたため、「Kintoneにあるけどパートナー中央に対応フィールドがない」「逆にAPIに必要な項目がKintoneにない」という問題がほとんど発生しませんでした。

ACEを意識して設計されたKintoneアプリは、そのままPartner Central連携の土台として機能したわけです。

もしKintoneアプリが社内独自の項目体系で作られていた場合、「どのフィールドをどう対応させるか」の設計だけで相当な時間がかかっていたと思います。

2. 開発者＝Kintoneアプリ管理者＝AWS管理者＝実際の利用者だった

今回の開発では、私一人が以下のすべての役割を担っていました：

役割	通常の開発では
要件定義者（何を作るかを決める人）	ビジネス担当者
Kintone管理者（フィールド追加・Webhook設定）	情報システム部門
AWS管理者（IAM・Lambda・EventBridge設定）	インフラエンジニア
開発者（コードを書く人）	開発エンジニア
テスター・利用者（実際に使う人）	現場担当者

通常の開発プロジェクトでは、これらの役割が別々の人・部署に分かれます。「フィールドを追加したいが情報システム部門の承認が必要」「テストしたいが本番環境へのアクセス権がない」といった待ち時間が積み重なります。

利用者が開発者であり管理者でもあるという状況では、「試したい→すぐ試せる→すぐ直せる」のサイクルが超高速になります。AIが生成したコードをその場でデプロイし、Kintoneで実際に入力して動作確認し、エラーが出たらすぐ修正。この意思決定の速さが1週間完成を可能にした大きな要因です。

教訓: バイブコーディングは「権限を持った当事者が自ら開発する」場面で最大の威力を発揮します。

開発中にハマったポイント（AWSパートナー向けナレッジ）

ここからは、同じようにPartner Central連携を検討しているAWSパートナーの方々に向けて、具体的な技術ナレッジを共有します。

1. APIパラメータの配置が直感と異なる

Partner Centralの画面上のセクションとAPIのオブジェクト構造が一致しません。

画面上の位置	想定するパス	実際のAPIパス
プロジェクト情報 > ソリューション	`Project.Solutions`	`RelatedEntityIdentifiers.Solutions`
プロジェクト情報 > クローズ日	`Project.TargetCloseDate`	`LifeCycle.TargetCloseDate`
プロジェクト情報 > タイプ	`Project.OpportunityType`	`OpportunityType`（トップレベル）
プロジェクト情報 > 月間収益	`Project.ExpectedMonthlyRevenue`	`Project.ExpectedCustomerSpend`（配列）

ドキュメントを注意深く読まないと、ParamValidationErrorが頻発します。

2. 画面の「パートナープロジェクト名」はProject.Title

これがAIにとって一番やっかいだったようです。Partner Central画面上の「パートナープロジェクト名」という項目、てっきり PartnerOpportunityIdentifier というパラメータだとAIは思っていたのですが、実際には Project.Title がその値を受け取ります。

PartnerOpportunityIdentifier はシステムが自動採番する内部IDで、こちらに入力しても画面のパートナープロジェクト名には反映されません。しかもエラーにはならないため、「入力したはずなのに表示されない」という謎の状態になります。

CloudWatchログでKintone側の値を確認したところ、Kintoneのフィールド値自体は正しく入っていました。つまりコードのマッピングが間違っていたわけです。AIに「AWSの画面でパートナープロジェクト名フィールドが正しく表示されない」と伝えると、APIリファレンスを調べて Project.Title が正解であることを突き止めてくれました。

3. EventBridgeはus-east-1固定

Partner Central Selling APIのイベントはus-east-1のEventBridgeにのみ発行されます。Lambdaもus-east-1に配置する必要があります。東京リージョン（ap-northeast-1）では受信できません。

4. EventBridgeのdetail-typeフィルタは広めに設定する

最初は Opportunity Created と Opportunity Updated の2種類のイベントだけをフィルタしていました。ところが、AWSが審査してステータスをApprovedやAction Requiredに変更するときは、これとは異なるイベントタイプで発火することがわかりました。

「Kintoneで登録した案件がAWSで承認されたのに、Kintone側のステータスが更新されない」という問題の原因がこれでした。解決策は detail-type フィルタを削除して、aws.partnercentral-selling ソースの全イベントを受け取る設定にすることです。

5. UpdateOpportunityにはLastModifiedDateが必須

楽観的ロック制御のため、更新前にGetOpportunityで現在のLastModifiedDateを取得し、そのままUpdateに渡す必要があります。この仕様を見落とすとエラーになります。

6. Marketing.SourceはUpdateで必須

CreateOpportunityでは任意ですが、UpdateOpportunityではMarketing.Sourceが必須です。未送信だとエラーになるため、Kintone側で未選択の場合はデフォルト値Noneを送信する設計にしました。

7. Kintone APIのCB_IJ01エラーの正体

Kintone APIが返すCB_IJ01: 不正なJSON文字列ですは、JSON構文エラーだけでなく、フィールドの型に対して不正な値構造を送った場合にも発生します。例えば、ドロップダウン（単一選択）フィールドに配列を送信するとこのエラーになります。

エラーメッセージからは原因が特定しにくいため、フィールドを1つずつ追加して切り分けるデバッグが有効です。

8. 無限ループ防止の設計パターン

双方向同期の無限ループ防止には複数の方式がありますが、「同期フラグ方式」はKintoneでは機能しません。フラグのリセット自体がWebhookを発火させ、3回目のループが発生するためです。

推奨方式: KintoneのWebhookペイロードに含まれる「更新者」フィールドを確認し、APIトークンに紐づくbotユーザーからの更新であればスキップする方式が最もシンプルかつ確実です。

9. ソリューションの関連付けはAssociateOpportunity APIで行う

ソリューション情報はCreate/UpdateOpportunityのパラメータとして送れません。AssociateOpportunity / DisassociateOpportunity という専用APIを使って別途関連付ける必要があります。

また、Kintone側でソリューションを表示するには名前が必要ですが、APIが返すのはIDのみです。ListSolutions APIで名前を解決してから書き込みます。この際、Kintoneの複数選択フィールドの選択肢として 事前に登録されていない値は保存できないため（CB_VA01エラー）、新しいソリューションIDが返ってきた場合はKintone管理画面への手動追加が必要です。

なお、ソリューション名のフォーマットは S-XXXX - ソリューション名（ハイフンスペースで区切る）で統一する必要があります。スペースだけで区切ると選択肢と一致しなくなります。

10. オポチュニティ提出（Submit）は2ステップ

案件をAWSのレビューに提出するには、SubmitOpportunity を直接呼ぶのではなく、まず StartEngagementFromOpportunityTask APIでエンゲージメントを作成する必要があります。エンゲージメントなしで SubmitOpportunity を呼ぶと ValidationException: Cannot submit opportunity without an engagement というエラーになります。

しかも StartEngagementFromOpportunityTask 自体にも、呼び出し時に AwsSubmission パラメータ（InvolvementType と Visibility）が必要です。このパラメータを渡さないと Missing required parameter in input: "AwsSubmission" というエラーになり、エラーは出るものの続く SubmitOpportunity の呼び出しに進んでしまうため、「エラーログを見ると失敗しているが、何度試してもSubmitできない」という状態になります。

最終的には StartEngagementFromOpportunityTask に AwsSubmission を渡すだけで、エンゲージメント作成とSubmitOpportunityが一括で非同期実行されることがわかりました。このAPIが内部でSubmitまで行ってくれるため、別途 SubmitOpportunity を呼ぶ必要はありません。

client.start_engagement_from_opportunity_task( Catalog="AWS", ClientToken=str(uuid.uuid4()), Identifier=aws_opp_id, AwsSubmission={ "InvolvementType": "Co-Sell", # または "For Visibility Only" "Visibility": "Full", }, )

InvolvementType の使い分けは以下の通りです：

値	意味	使うとき
`Co-Sell`	共同販売	AWSセールスのサポートが必要な案件
`For Visibility Only`	情報共有のみ	自社完結で進める案件（AWSに見えるようにするだけ）

11. Kintone選択肢の日本語表記はシステムと一致させる

変換マップのキーとKintoneの実際の選択肢文字列が1文字でも違うとマッピングが空文字になり、INVALID_ENUM_VALUE エラーが発生します。

例として「オポチュニティタイプ」の選択肢名称の問題がありました：

変換マップに書いていた文字列	Kintoneの実際の選択肢
`更新`	`事業更新(Flat Renewal)`
`拡大`	`拡大(Expansion)`

エラーメッセージは Value '' at 'opportunityType' failed to satisfy constraint のように 空文字が送られたという内容になります。空文字になるのはマップにキーが存在せず、.get() がデフォルト値を返しているためです。このパターンを覚えておくと原因特定が早くなります。

バイブコーディングのコツ

1. 設計書を「AIの外部記憶」にする

AIとの対話はセッションごとにリセットされます。設計書をMarkdownで作成し、新しいセッションの冒頭で読み込ませることで、過去の文脈をすべて引き継げます。

実際、今回の開発では設計書が生まれ、テスト中に判明した修正事項21件、運用注意事項まですべて設計書に蓄積しました。「前回どんな問題があったか」「なぜこの設計にしたか」を設計書のトラブルシュート記録セクションに残しておくことで、運用フェーズでの問題解決も格段に速くなります。

2. エラーログはそのまま貼る

CloudWatchのログやエラーメッセージは、加工せずそのままAIに貼り付けてください。AIはスタックトレースやエラーコードのパターンを認識し、原因と修正案を提示してくれます。

「こういうエラーが出ました」と要約するよりも、生のログのほうがAIには情報量が多く、正確な判断ができます。

3. 一気に作らない、段階的に動かす

最初から全機能を実装しようとせず、最小限の構成で動作確認してから機能を追加していく進め方が重要です。

今回も「まずCreate、次にUpdate、最後に逆方向」という順序で段階的にテストし、各段階でエラーを潰していきました。

4. 人間がやるべきこと

バイブコーディングで「AIがやってくれること」と「人間がやるべきこと」は明確に分かれます。

AIがやってくれること:

コードの生成・修正
API仕様の調査
エラーの原因特定
設計書の作成・更新
値変換マップの網羅的な作成

人間がやるべきこと:

AWSコンソールでのリソース作成（IAMロール、Lambda、API Gateway、EventBridge）
Kintone管理画面でのフィールド設定
デプロイ作業
実環境でのテスト実行と結果確認
ビジネス要件の判断（どのフィールドを同期するか等）

つまり、AIは「考えて書く」部分を担当し、人間は「設定して動かす」部分を担当します。

コスト比較

項目	従来開発	バイブコーディング
期間	約12週間	約1週間（＋運用後の追加修正数日）
人員	エンジニア1〜2名	非エンジニア1名 + AI
外注費	一般的には数百万円くらいかかるでしょうか	AIツール利用料のみ
成果物	コード + 簡易仕様書	コード + 詳細設計書（トラブルシュート記録付き）
保守性	開発者に依存	設計書があればAIで修正可能

特筆すべきは、設計書の充実度です。従来の開発ではドキュメントが後回しになりがちですが、バイブコーディングでは設計書がAIとの「共有記憶」として不可欠なため、開発と同時に自然と詳細なドキュメントが生まれます。

また、運用開始後に発生したバグ修正も、設計書にトラブルシュート記録を積み重ねていくことで、同じ問題が再発した際の解決が非常に速くなります。

使ってみてどうなのか

めんどうだったACEへの案件登録作業が掛け値無しに楽になりました。入力項目をACE側が必須項目とするものに限定し、初期値を活用することで入力時間の大幅短縮が実現できました。メンバーからも大好評です。

まとめ

AWS Partner Central × Kintone連携は、多くのAWSパートナーが「やりたいけど手が出ない」と感じている領域ではないでしょうか。

本記事で紹介した通り、バイブコーディングを活用すれば、プログラミング未経験者でも1週間で実用的な双方向連携を構築できます。必要なのは、AWSとKintoneの基本的な操作スキルと、AIへの適切な指示の出し方だけです。

Partner Central Selling APIはまだ情報が少なく、本記事で紹介したハマりポイント（特に「提出にはエンゲージメント作成が必要」「EventBridgeのフィルタは広めに」「パートナープロジェクト名はProject.Title」）が少しでも皆さまの参考になれば幸いです。

「AIに任せる部分」と「人間がやる部分」を正しく切り分ければ、今まで専門家に頼るしかなかったシステム連携を、業務担当者自身が実現できる時代が来ています。