AIペアアーキテクトのすすめ（第1回）
仕様もAPIも決まっている状態から、AIと実装方針を詰めていく。
AWS Kiroを使い、設計の迷いをAIと対話で整理する「Chat駆動開発」を全3回で実践的に紹介します。
コードを書く前に、AIと“どう作るか”を相談する
仕様もAPIも決まっている。
それでも、「どう実装すればいいのか」 で手が止まることがある。そんなとき、AIを「設計の相談相手」にしてみると、驚くほどスムーズに前へ進める。
コードが書けるAIの次に来るもの
生成AIが書くコードは、今や十分に実用レベルに達しています。
ただ、実務で使うとすぐに気がつくのが、「正しいコードよりも、正しい方針を選ぶことのほうが難しい」 という現実です。
たとえば次のような場面を経験したことはないですか？
- Slack通知を送る小さなスクリプトを作りたい
- APIの仕様も、利用する言語（Python）も決まっている
- でも「SDKを使うか」「requestsで直叩きするか」「リトライ処理をどう書くか」で迷う
この実装方針の迷いは、AIにコードを全部書かせるよりも難しいかもしれません。
なぜなら、「何を重視するか」＝設計の判断基準が、プロジェクトごとに違うことが往々にしてあるからですね。
AIを「ペアアーキテクト」として使う発想
ここで登場するのが、AWSのAI開発支援環境 Kiro です。
Kiroは単なるコード生成AIではなく、設計・実装方針をAIと相談しながら進めるためのペアアーキテクトのような存在になります。
ChatGPTのような会話型AIに似ているんですが、IDEとしてプロジェクト全体の文脈を理解し、ファイル構造・ライブラリ選定・APIの呼び出しパターンなども踏まえて回答してくれるのが特徴です。
Kiroを使うと、次のような対話ができる：
Slack通知を送るツールを作りたい。SDKを使うかrequestsで実装するか、どちらが良い？
Slack通知ツールの実装方法について、それぞれのメリット・デメリットを整理しますね。
SDK vs requests の比較
Slack SDK（slack-sdk）を使う場合
メリット:
型安全性とIDEサポートが充実
エラーハンドリングが組み込まれている
レート制限の自動処理
豊富なSlack API機能に簡単アクセス
公式サポートで安定性が高い
デメリット:
依存関係が増える
パッケージサイズが大きい
requests を使う場合
メリット:
軽量で依存関係が少ない
実装が透明で制御しやすい
必要最小限の機能のみ実装可能
デメリット:
エラーハンドリングを自分で実装
レート制限対応が必要
型安全性が低い
推奨案
シンプルな通知のみ → requests 複雑な機能や将来の拡張性 → SDK
どちらの実装パターンも作成できますが、どのような用途を想定していますか？基本的なメッセージ送信だけか、ファイルアップロードやインタラクティブな機能も必要かを教えてください。
人間はKiroが表示された提案をもとに最終判断をします。
AIは「考える材料」と「比較の軸」を出してくれるわけです。
この関係性こそ、ペアアーキテクト的なAIの使い方じゃないでしょうか。
Spec駆動開発でもVibeコーディングでもない「中間のスタイル」
AIコーディングのスタイルを大きく分けると、よく次の2つが挙げられます。
| スタイル | 概要 | 向いている場面 |
|---|---|---|
| Spec駆動開発(SDD) | 要件定義や仕様書をAIに渡し、コードを生成させる | 大規模・明確なシステム開発 |
| Vibeコーディング | 「ざっくりこんなものを作りたい」と会話しながら構築する | 試作・UIモック・発想探索 |
どちらも強力だが、実務で一番多いのはその中間層じゃないでしょうか。
- 作りたいものは明確（例：CLIツール、API連携スクリプト）
- 使う技術も決まっている（例：Python + Slack API）
- でも、どんな実装パターンにするかで悩んでいる
この「仕様は決まっているけど設計が曖昧」なゾーンこそ、Kiroの得意領域といえます。
AIに丸投げするのではなく、相談しながら設計を詰めていく。
これを「Chat駆動開発(Chat Driven Development)」と呼んでみたいとおもいます。
会話の始め方 ― 要件をどう伝えるか
AIと話すときに重要なのは、「すべてを説明しないこと」ではなく、「前提を明確にすること」でしょう。
Kiroをうまく使うための最小限の情報は、次の3つだけです。
- 目的（何をしたいのか）
> 「Slackに日次レポートを投稿するCLIを作りたい」 - 技術条件（言語・ライブラリ・制約）
> 「Python、Slack Web API、requestsのみ利用可」 - 運用想定（実行環境・依存など）
> 「cronから実行」「APIトークンは環境変数で管理」
この状態でAIに質問する。
「この構成なら、どんなディレクトリ構成・関数分割が良い？」
「Rate limitを考慮した再送処理はどう組むのが自然？」
こうして出てきた案を比較しながら、「自分がどうしたいか」を明確にしていきます。
AIに比較させて、判断を人間が行う
AIに「コードを書かせる」よりも、「比較をさせる」ほうが、設計の質が高まります。
たとえば次のように依頼してみましょう：
「同期実装と非同期実装の2パターンを出して、メリットとデメリットも説明して」
Kiroはこのように答えるかもしれない。
- 同期実装：シンプルでデバッグが容易。少数リクエストに向く。
- 非同期実装：多数の通知に高速。例外処理が複雑。
人間はこの比較から、「今回は単発通知だから同期で十分だな」と判断できますね。
AIが提示するのは選択肢の地図で実際に進むルートは自分で決めるわけです。
鵜呑みにせず、「なぜそうなるのか」を聞く
AIに設計相談をするとき、もうひとつ重要なのが、理由を必ず尋ねることです。
「なぜこの関数構成が良いの？」
「この実装方針の欠点は何？」
「他の選択肢と比べてどこが優れている？」
こうした質問を重ねると、AIの回答も構造的になり、単なる「コード提案」から「アーキテクチャ議論」へと深まっていきます。
AIとの会話を意思決定のドキュメントにしておくと、後から「なぜこの構成にしたのか」をチームで共有できる点も大きな利点ですね。
まとめ ― 設計はAIと一緒に考える時代へ
AIにコードを書かせる時代は、すでに当たり前になりつつあります。
これからはその先、設計・構成・方針といったコードの前段をどう支援させるかがAIの使い所じゃないでしょうか。
AWS KiroのようなAI IDEを使うと、人間が判断し、AIが材料を出すという、ちょうど良い分担ができます。
- AIに“実装の比較”をしてもらう
- AIに“理由”を説明させる
- 人間が“採用案”を決める
これが「AIペアアーキテクト」という新しい開発スタイルだとおもいます。
次回予告
次回（第2回）では、実際にKiroと会話しながら、Python + Slack API で日次レポート通知ツールを設計していく実例を紹介します。
「AIとどう話すと、設計の質が上がるのか？」を、実際のプロンプトと回答で具体的に見ていきます。
（第1回おわり）
コメント