思いどおりに進まなかったバイブコーディングを振り返り、次回のAI開発を考えてみた

本記事は 夏休みクラウド自由研究2026 8/17付の記事です

こんにちは。SCSK渡辺(大)です。

現在、Spec駆動開発、AI-DLC、ループエンジニアリングといったAI開発の手法を十分に学ばないまま、いわゆるバイブコーディングでAIに頼りアプリケーション開発をしています。
その経験をもとにして、次回のAI開発ではどのようにすべきかを考えてみました。

初めてAIを使ってアプリケーション開発をする、または、仕事などでAIを使った開発を始めることになったなど、私と同じ境遇の方の一助になれば幸いです。

 

注意:
本記事の内容は、あくまで一個人の見解です。正確な情報を保証するものではありません。
AIに関する製品やサービスは変化が速いため、2026年8月16日時点の内容であること、あらかじめご了承ください。
 

まずはじめに

AIにかかるコストは高いです。また、AIに100%を求めないことも重要です。

コスト削減のためにすべきこと

  • 自分でできることは、自分で行う
  • 自分でできることもAIに任せたい場合は、ルールを決める

いずれも、すでに多くの方が発信している内容ですが、今回の開発を通して、私自身もその重要性を非常に強く感じました。

注意:
公式が公開しているルールや、ほかの人が推奨しているルールが、そのまま自分の環境に当てはまるとは限りません。実際の環境や開発対象に合わせて調整する必要があります。

 

個人の環境

私が主に使用しているエージェント、ハーネス、サーフェス(利用者が操作する接点)は以下のとおりです。
コストについては、Microsoft 365 Copilotは全社配布より無料で利用でき、KiroよりClaude Codeのほうがコストが高いという印象です。
Claude CodeはBedrock経由で使用しています。

ベンダー エージェント ハーネス サーフェス
Microsoft Microsoft 365 Copilot Microsoft 365 Copilot ブラウザ版Copilot Chat
AWS Kiro Kiro統合エージェントハーネス CLI、IDE
Anthropic Claude Code Claude Code CLI、Desktopアプリ

 

私が主に使用しているモデルは以下のとおりです。

モデルベンダー モデルファミリー モデル名
Anthropic Claude Claude Fable 5
Anthropic Claude Claude Opus 4.6
Anthropic Claude Claude Sonnet 5
OpenAI GPT-5.6 GPT-5.6 Luna
OpenAI GPT-5.6 GPT-5.6 Sol

 

個人的な最適解 ~次回のAI開発ではどのようにすべきか~

ここで紹介する内容は、今回の開発で最初から実践できていたものではありません。
今回の開発で失敗した経験を踏まえ、今後はこのように進めたいと考えている個人的な最適解です。

AIのコストを下げるためには、利用するモデルだけでなく、レビュー回数やAIへ任せる範囲についてもルールを決める必要があります。

使い分けるもの

1つの製品やモデルですべてを完結させず、作業に応じて使い分けます。

  • ハーネス
  • モデル
  • 推論レベル
  • 作業ディレクトリ

ハーネスの使い分け

ハーネス 主な用途
Microsoft 365 Copilot
  • 画像生成
  • 社内ルールの確認
Kiro
  • 要件定義書の作成
  • 計画書の素案作成
  • Git全体を確認する必要がある調査
  • インターネット検索と、その結果をまとめた資料の作成
  • Claude CodeからヘッドレスでGPTモデルを呼び出す
Claude Code
  • 計画書の確定
  • 計画書を確定する際のFable利用
  • 実装までのすべての作業

複数のハーネスを使い分けるデメリット

  • 1つの製品で完結しないため、画面の切り替えが面倒になる
  • 別のエージェントへ引き継ぐための資料を作成してもらう必要がある

デメリットをできるだけ減らすために:
開発しながら行うインターネット検索や、その結果をまとめた資料の作成については、Microsoft 365 Copilotへ切り替えず、Kiroなどで安価なモデルへ切り替えて行うことを推奨します。

開発の流れ

工程 作業 ハーネス 使用モデル レビュー
要件定義書と計画書素案の作成 Kiro L1:
Claude Opus
またはGPT-5.6 Sol
次工程で確認
計画書の修正と確定 Claude Code L1:Claude Fable
L2:Claude Sonnet
KiroヘッドレスでGPT-5.6 Solのレビューを受ける
実装 Claude Code L1:Claude Fable
L2:GPT-5.6 LunaまたはClaude Sonnet
計画書で整理したレビュー体制に準ずる

 

① Kiroで要件定義書と計画書素案を作成する

Kiroを使い、要件定義書と計画書の素案を作成します。
L1では、Claude OpusまたはGPT-5.6 Solを使用します。
この段階では計画書を確定せず、後続工程でClaude Codeに確認してもらうための素案として作成します。

② Claude Codeで計画書を確定する

Claude Codeに、Kiroで作成した要件定義書と計画書素案を確認してもらいます。
計画書が確定するまで、内容を修正します。

重要:
レビューは最大3回までとします。回数の上限を設けずにレビューを続けると、修正しても新たな指摘が出てくるなどして飽和し、AIの利用コストが増え続ける可能性があります。
 
計画書作成時に含める依頼
  • レビュー担当のGPT-5.6 Solは、レビューのたびに要件定義書を読み直すこと
  • 各作業の難易度を「低・中・高」の3段階で付けること
  • 編集作業が競合しないように、並行度を上げて進められる作業を整理すること
  • 各作業のレビューを担当するモデルを整理すること
  • 各作業のレビューは最大3回までとすること
  • 本筋から逸れるレビュー指摘には対応しないこと
  • その他についてはFableに任せること

要件定義書を毎回読み直してもらう理由:
依頼の仕方に問題があった可能性もありますが、過去にAIが要件を取りこぼしたり、実際には実装していない内容を実装したと報告したりすることがありました。そのため、レビューのたびに要件定義書を読み直してもらうことを推奨します。
「その他はFableに任せる」について:
Fableについては具体的に指示しすぎるのは良くないという声を見かけるため、あえて詳細を決めすぎず、抽象的に依頼します。

 

③ Claude Codeで実装する

計画書が確定したら、Claude Codeに実装してもらいます。

L1では、Claude Fableを使用します。
L2で実行する権限がない作業についてはL1で作業する必要がありますが、作業を始める前に必ず安価なモデルへ切り替えます。

L2では、KiroヘッドレスからGPT-5.6 Lunaを呼び出します。
ただし、Kiroヘッドレスでは実行できず、Claude Codeのサブエージェントとして作業する必要がある場合は、Claude Sonnetを使用します。

レビュー体制は、計画書で整理した内容に準じます。

Claude Codeを利用する理由:
Fableを利用できること、auto modeがあること、一時点で同時に稼働しているサブエージェントのすべてが完了を待たないこと、処理中であっても追加の指示や質問にある程度対応してくれること、といったことが挙げられます。
1点目以外はKiroでも対応できる部分もあるかと思いますが、1点目が理由として最も大きいです。

 

実装時に含める依頼
  • Fableはオーケストレーションに徹すること
  • 判断が必要なことが発生した場合は、FableとSolで会話して決めること
  • FableとSolでも判断できない場合は、私に質問すること
注意:
判断をAIに任せることは、状況によっては悪手になり得ます。
実際の挙動やリスクに注意して利用する必要があります。
 

感想

AIにかかるコストは本当に高いため、それを下げるためのルールを作ることが大切だと感じています。

一方で、現状は私自身の知見が不足しているため、AIに頼りすぎてコストが増加しています。
AIの使い方も学ばなければなりませんが、それだけでなく、自分自身のスキルアップも必要です。
そのため、現時点では、AIによって業務が楽になったとは、まだ言い切れないと感じています。

別の話をすると、AI界隈では最近、CodeXが盛り上がっているように感じます。
つい先日、Lunaもマルチエージェントv2に対応したようなので、触ってみたいと思います。
また、Grok 4.6が出たばかりですが、Grok 4.7を示唆する情報も出ているため、置いて行かれないようにCursorとGrokBuildも触ってみたいです。

とはいえ、正直なところ、少しAI疲れも感じています。
新しい製品やモデルを急いで試すのではなく、少し落ち着いてから取り組もうと思います……。

 

まとめ

  • AIにかかるコストは高い
  • AIに100%を求めない
  • 自分でできる作業は、自分で行うことも検討する
  • AIに任せる場合は、自分の環境に合ったルールを決める
  • ハーネス、モデル、推論レベル、作業ディレクトリを使い分ける
  • 作業の難易度に応じてモデルを切り替える
  • レビューのたびに要件定義書を読み直す
  • レビュー回数には上限を設ける
  • 本筋から逸れるレビュー指摘には対応しない
  • AIだけで判断できない場合は、人間へ確認を戻す
  • AIの使い方だけでなく、自分自身の開発スキルも高める

 

以上。

本記事に不備がございましたら、ご連絡いただけますと幸いです。

×
タイトルとURLをコピーしました