本稿は、ゲーム、積算・原価シミュレーションツール、管理会計、中長期経営計画という複数の開発経験をもとに、Vibe Codingを業務システム開発へ発展させる方法を整理したものです。掲載事例では企業名、個人名、固有の業務数値、内部システム名などを一般化しています。
はじめに
Fableが公開されてからの数週間、生成AIを使って、いくつかのデジタルシステムを猛烈に構築してきました。
最初に作ったのはナインボールのビリヤードゲーム。画面上で球が動き、衝突し、ポケットへ入り、CPUと対戦できます。狙いを定め、ショットの強さや回転を調整すると、その結果がすぐに画面へ返ってきます。自分の言葉が短時間で動くソフトウェアへ変わる体験は、強烈でした。
その後、積算・原価シミュレーション、管理会計、中長期経営計画と、対象をより複雑な業務へ広げていきました。そこで分かったのは、ゲームを素早く作ることと、業務で信頼して使えるシステムを作ることは、同じAIコーディングであっても要求される設計が大きく異なるということです。
ゲームや画面モックは、動かして体感することで改善できます。一方、管理会計や経営計画では、画面が正しく見えるだけでは足りません。数値がどこから来たか、誰が何を承認したか、前提が変わったときにどこへ影響するか、同じ入力から同じ結果を再現できるか、誤ったデータをどこで止めるかまで説明できなければなりません。
もう一つの大きな発見は、すべての作業を一つのAIモデルへ任せる必要はないということでした。
要件を深く考える作業、設計上の契約を作る作業、難しい計算を実装する作業、文書化された仕様を正確にコードへ落とす作業、実装者とは独立した立場で欠陥を探す作業では、求められる能力が違います。そこで、Claude CodeのFable、Opus、Sonnetと、CodexのGPT-5.6 Solを、役割の異なる開発チームのように使い分けました。
その結果、高度な推論能力を本当に必要な工程へ集中し、仕様が確定した実装は効率のよいモデルへ渡し、完成した成果物を別系統のAIにレビューさせる流れが生まれました。文書をAI間のインターフェースとして使うことで、毎回すべての経緯を会話で説明し直す必要も減りました。
本稿で伝えたいのは、特定モデルの性能ランキングではありません。
重要なのは、要件定義、設計、実装計画、実装、テスト、レビュー、承認を一つの仕事として混ぜず、それぞれに適したAIと人間の役割を設計することです。それによってVibe Codingは、速い試作から、精度、説明責任、再現性を備えた業務システム開発へ進化します。
第1部 Vibe Codingの可能性を体感する
第1章 ナインボールが教えてくれたVibe Codingの衝撃
「作りたい」が動くものになる
ナインボールは、HTML、CSS、JavaScriptを中心とした小さな構成で作りました。小規模な構成でありながら、球の衝突、クッションとの反射、ポケット判定、ファウル、ターン制御、CPUのショット選択、回転、狙いの補助線など、ゲームとして体感できる要素を組み込むことができました。
ここで重要だったのは、最初から完璧なゲーム設計書を作ったことではありません。まず動くものを作り、プレイしながら違和感を言葉にし、その場で修正していったことです。
球が速すぎる、狙いが敏感すぎる、CPUが不自然な方向へ打つ、ファウル後の処理が分かりにくいです。こうした問題は、画面を触ればすぐに分かります。人間が感覚で評価し、AIがコードへ反映するサイクルが非常に短いです。
この体験によって、生成AIを単なる質問応答ツールではなく、ソフトウェアを一緒に作る相手として認識するようになりました。
ゲーム開発から得た本質的な学び
ゲーム開発から得た最大の学びは、完成度より先にフィードバック可能性を作ることの価値でした。
文章だけで議論していると、参加者はそれぞれ違う画面や挙動を想像します。動くものがあれば、議論は具体的になります。これは後の業務システム開発でも変わりませんでした。
ただし、ゲームでは体感的に正しければ受け入れられる場面が多いのに対し、業務システムでは体感だけでは足りません。金額、権限、履歴、承認、再実行、監査、外部連携など、画面から見えない品質が重要になります。
ナインボールは、Vibe Codingの入口として非常に有効でした。同時に、業務システムへ進むには別の規律が必要であることを理解する出発点にもなりました。
第2章 Claude Codeが「対話」を「共同開発」に変えた
VS Codeの中に開発パートナーがいる感覚
ナインボールを作ったとき、もう一つ強く感動したことがあります。それは、Claude CodeをVS Codeの拡張機能として使った体験です。
それまでの生成AIは、ブラウザで質問し、回答として表示されたコードを人間がコピーし、エディタへ貼り付け、エラーが出たら再びブラウザへ戻るという使い方が中心でした。この方法でもコードは作れますが、AIと実際の開発環境の間を人間がつなぎ続けなければなりません。
Claude CodeをVS Codeの中で使うと、その関係が大きく変わりました。
AIが実際のプロジェクト構成を読み、関連する複数ファイルを確認し、必要な箇所を編集し、ターミナルでコマンドを実行し、結果を見て次の修正へ進みます。人間は「どのコードをコピーするか」ではなく、「何を実現したいか」「今の挙動のどこが違うか」「次に何を優先するか」へ集中できます。
画面上の球の動きについて要望を伝えると、AIが関連する物理演算や描画処理を探し、変更し、再び実行可能な状態へ整えます。機能を追加するときも、一つのコード断片だけでなく、既存のファイル構成やゲーム全体の流れを踏まえて作業が進みます。
この体験によって、生成AIが「コードを教えてくれる相手」から「同じ開発環境で作業する相手」へ変わりました。
感動の中心はコード生成量ではない
Claude Codeを使った感動の中心は、一度に大量のコードを生成できることだけではありません。
- 実際のプロジェクトを前提に会話できること
- 複数ファイルをまたいだ変更を任せられること
- ターミナルの実行結果を次の修正へつなげられること
- エラーの原因調査から修正、再検証まで往復できること
- 人間が意図と評価に集中できること
これらが一つの流れとしてつながったことに価値がありました。
自分一人で開発しているにもかかわらず、設計や実装について相談でき、必要な変更をその場で進め、動作確認まで一緒に行う開発パートナーがいるように感じられました。私にとって、この環境がなければ、その後の積算、管理会計、中長期経営計画へ取り組むところまで到達できなかったと思います。
人間の役割も変わる
エディタ統合型のコーディングエージェントを使うと、人間がコードを一行ずつ入力する時間は減ります。しかし、人間の仕事がなくなるわけではありません。
何を作るのか、どこまで作るのか、動作が期待どおりか、業務上の意味が正しいか、リスクを受け入れてよいかは、人間が判断します。AIが作業環境へ深く入るほど、目的、制約、レビュー、承認を人間が明確にする必要があります。
つまり、エディタ統合によって人間の役割は、コードの入力作業から、意図の提示、品質評価、意思決定へ移っていきます。この役割変化が、後に要件定義や設計文書を重視することにもつながりました。
Codex IDE extensionというもう一つの選択肢
現在は、CodexにもVS Codeおよび互換エディタで利用できるIDE拡張があります。
OpenAIの公式マニュアルでは、Codex IDE extensionから選択したコードやファイル全体を会話のコンテキストへ追加できること、作業ディレクトリ内のファイルを読み、編集し、コマンドを実行できること、Git差分を対象としたレビューをIDE上から実行できることが説明されています。これらの操作は、サンドボックスと承認設定の下で制御されます。
したがって、Claude CodeとCodexは製品や操作感が完全に同じではありませんが、「エディタの中で実際のプロジェクトを共有し、AIと実装、実行、検証を往復する」という同種のVibe Codingを実現する選択肢として考えられます。
Codexについては、OpenAI公式ドキュメントのCodex IDE extensionで、現在の対応環境と機能を確認できます。
ツールを競わせるのではなく、選択肢として持つ
重要なのは、Claude CodeとCodexのどちらか一方だけを正解にすることではありません。
エディタとの一体感、利用できるモデル、レビュー機能、権限制御、料金、チームの開発環境などを踏まえて選択できます。また、主軸の実装にはClaude Codeを使い、独立レビューにはCodexを使うといった組み合わせも可能です。
一つのAIへすべてを閉じるのではなく、各ツールの強みと独立性を生かす発想が、後のマルチモデルAI開発へつながりました。
Vibe Codingの入口としての開発環境
Vibe Codingを初めて体験する人には、まず小さな題材を選び、Claude CodeやCodexのIDE拡張を使って、要求、編集、実行、確認の一巡を体感することを勧めます。
重要なのは、最初から大規模な業務システムを作ることではありません。自分の言葉が実際のプロジェクトへ反映され、動作結果を見ながら改善できる感覚をつかむことです。
この体験が、AIを便利な検索やコード生成の道具としてではなく、開発工程そのものを変える存在として理解する第一歩になります。
第3章 積算・原価シミュレーションツール――モックから本番指向システムへ
まず業務の流れを画面にする
次に取り組んだのは、積算・原価シミュレーションのモックでした。
案件を選び、外部で作成された数量データを取り込み、工種テンプレートと標準単価を使って原価を積み上げ、担当者がレビューし、確定後にCSVやPDFを出力します。こうした一連の業務を、複数画面からなるモックとして表現しました。
初期版では、本番用のデータベース、認証、権限管理を作り込まず、ブラウザ内のデータ保存を使いました。目的は本番運用ではなく、画面構成と業務フローを短期間で確認することだったからです。
この段階で「実装しないこと」を明示した点も重要でした。案件の発生、図面読取り、商品マスタの更新など、他システムや別業務が担当する範囲をモックへ持ち込まないようにしました。AIは指示された機能を増やすことが得意であるため、作らないものを定義しないと、システムは簡単に膨張します。
モックは要件発見装置である
モックを操作すると、文章だけでは見えなかった論点が現れます。
どのステータスで工法を変更できるのでしょうか。標準単価はいつ時点のものを使うのでしょうか。確定後にマスタ単価が変わった場合、過去の原価も変わるのでしょうか。数量は小数を持つのでしょうか。金額はどの単位で丸めるのでしょうか。確定後に修正が必要になった場合、上書きするのでしょうか、それとも取消と再確定にするのでしょうか。
これらは画面デザインの問題ではありません。業務上の契約です。
モックの価値は、完成品に近く見えることではなく、このような未確定事項を早期に発見し、業務担当者と具体的に議論できることにあります。
本番化では見えない品質を作る
本番指向の実装では、構成を改めました。データベース、認証、行レベルのアクセス制御、監査ログ、サーバー側処理、自動テスト、E2Eテスト、エラー監視を加えました。
特に重要だったのは、業務ルールを画面の注意書きではなく、データベースとコードの両方で守ることでした。
- 金額は浮動小数ではなく整数として扱う
- 数量は必要な小数精度を保持する
- 適用日をもつ標準単価を選択する
- 原価確定時の単価をスナップショットとして保存する
- 確定済み明細は直接更新・削除できない
- 確定処理と監査記録を一つの処理として実行する
- ステータス遷移を一方向に制御する
- CSVでは文字コードと数式インジェクションを考慮する
この経験から、モックと本番システムの間には、単なる技術スタックの違いではなく、責任の違いがあると分かりました。
モックは問いを見つけます。要件定義は答えを合意します。設計は答えを守る仕組みに変えます。本番実装は、その仕組みが異常時にも壊れないことを証明します。
第2部 業務システム開発へ進化させる
第4章 管理会計システム――実装前の要件定義が品質を決める
いきなりコードを書かない
管理会計システムでは、実装より前に、機能カタログ、要件調査チェックリスト、プロジェクト原則、技術構成、共通部品計画、個社適用方針などを作成しました。
管理会計という言葉は同じでも、会社によって必要なシステムは大きく異なります。予算編成の複雑さ、見込管理の有無、配賦の方法、工事や案件の粒度、組織改編、多通貨、承認、Excel回収、既存システムとの連携など、実態はさまざまです。
参照製品の機能を調べることは有効ですが、製品の機能一覧をそのまま開発範囲にしてはいけません。重要なのは、対象企業の意思決定に必要な機能だけを選ぶことです。
要件調査は仮説を守るためではなく、捨てるために行う
初期段階では、業種や一般的な管理会計の知識から、重要と思われる論点を仮説として置きました。しかし、実際の要件調査を行うと、当初重要だと考えていた論点が対象企業ではほとんど発生せず、別のデータ捕捉や大量案件管理が中心課題になることが分かりました。
これは要件定義が機能した事例です。
要件調査の目的は、最初の仮説を正当化することではありません。事実によって仮説を更新し、不要な機能を捨て、重要な問題へ資源を集中することです。
AIは、与えられた前提を整然と展開する能力が高いです。だからこそ、前提が間違っている場合には、非常に精密な間違いを大量に作る危険があります。実装能力が高まるほど、要件調査の重要性も高まります。
現行業務の移植と新しい業務設計を区別する
要件定義では、既存業務をシステム化する部分と、これまで実施していなかった新しい管理プロセスを設計する部分を分ける必要があります。
既存業務であれば、現在の入力、計算、承認、例外を確認できます。一方、新しい見込管理やKPI管理は、現状を聞くだけでは要件が出てきません。誰が、いつ、何を入力し、どの会議で、どの粒度で判断するのかを新たに設計しなければなりません。
この違いを認識せずに「現行業務をヒアリングする」だけでは、新しい経営管理の仕組みは作れません。
汎用的SaaSを作らない
管理会計システムの開発原則として、「汎用的SaaSを作らない」を置きました。
汎用設定画面、ノーコードモデラー、あらゆる企業へ対応する複雑な権限設定などを作り始めると、小規模な開発は巨大な製品開発へ変わってしまいます。個社開発の強みは、その会社に必要なロジックを直接コードと定義へ落とせることにあります。
共通部品は、エンドユーザーに何でも設定させるためではなく、開発者が次の案件を安全に速く作るために用意します。共通と個社の境界を誤ると、再利用性を求めた結果、どの会社にも合わない複雑な基盤ができます。
そこで、共通基盤と個社実装を別のリポジトリに分けました。共通基盤は、データ取込、標準スキーマ、計算の基本部品、セマンティック定義、AI照会の安全装置、監査、リコンサイルなどを提供します。個社側は、マッピング、業務固有ディメンション、個社KPI、帳票構成などを持ちます。
個社で生まれた機能を共通へ戻す場合にも条件を設けました。条件は、複数案件で使う具体的な見込みがあること、顧客固有情報を除去できること、テストと文書を伴うことです。この関所が、先回りした汎用化を防ぎます。
第5章 文書を説明資料ではなくAI間の開発契約にする
AI開発における文書の役割
従来の開発でも文書は重要でした。しかし、AIを複数のセッションやモデルで使う開発では、文書の意味がさらに大きくなります。
会話だけに依存すると、前のセッションで決めたことが次のセッションへ正確に伝わりません。モデルが変われば、問題の捉え方も変わります。長い会話履歴を毎回すべて渡せば、重要な判断が大量の情報に埋もれ、トークンも消費します。
そこで、決まったことを正典文書へ固定します。
正典文書とは、単なる説明資料ではありません。実装者が迷ったときに戻る場所であり、レビュー担当が実装を評価する基準であり、内容が衝突した場合の優先順位を決める契約です。
文書はコンテキストを圧縮する
要件定義の議論が数時間、数日続いても、最終的な決定事項は数ページに整理できます。検討中の会話をすべて次のAIへ渡すのではなく、決定、理由、非対象、未確定事項を文書にまとめます。
これにより、次のAIは検討を最初からやり直す必要がありません。必要な文書と対象タスクだけを読めば十分です。文書化は作業を増やすように見えますが、実際には後続セッションのコンテキストを圧縮し、同じ説明や再検討を減らします。
設計が曖昧なまま実装モデルへ渡せば、実装モデルは不足部分を推測します。推測が外れると、コードだけでなくテストや帳票まで間違った方向へ整合してしまいます。逆に、入力、出力、例外、DoD、不変条件が明確であれば、実装モデルは限られたトークンで正確に作業できます。
文書の上下関係を決める
文書が増えると、どの文書が正しいか分からなくなる問題が起きます。そのため、次を決める必要があります。
- プロジェクトの最上位原則は何か
- 要件の正はどこにあるか
- データや計算仕様の正はどこにあるか
- 実装計画と現在の進捗はどこにあるか
- 判断変更はどこへ記録するか
- 古い文書をどのように廃止するか
- 文書とコードが衝突した場合にどうするか
文書の量より、関係が明確であることの方が重要です。
生きた文書として更新する
設計書とコードが一致しない場合、「コードが動いているからコードが正しい」とは限りません。コードが契約を破っている可能性も、文書が古い可能性もあります。
不一致を見つけたら、どちらが正しいかを判断し、コード、テスト、文書を同じ変更単位で揃えます。文書を更新しない小さな修正が積み重なると、次のAIは古い仕様を正しいものとして読み、手戻りを生みます。
文書を生きた状態に保つことは、将来の人間のためだけではありません。次のAIセッションの精度とトークン効率を守るための実装作業です。
第3部 AIモデルを開発チームとして編成する
第6章 なぜ一つのAIモデルにすべてを任せないのか
工程によって求められる能力は違う
要件定義では、曖昧な業務情報を整理し、利害や優先順位を踏まえ、何を作らないかまで考える必要があります。設計では、異常時や将来変更を含めた契約を作る必要があります。実装では、決められた仕様を漏れなくコードとテストへ変換する必要があります。レビューでは、実装者の意図から距離を取り、前提そのものを疑う必要があります。
これらを同じ会話、同じモデル、同じ視点のまま続けると、いくつかの問題が起きます。
第一に、高度な推論能力を必要としない定型実装にも、高コストなモデルを使い続けることになります。
第二に、設計と実装を同時に進めるため、実装中の都合で契約が曖昧に変更されやすくなります。
第三に、自分で作ったものを自分でレビューするため、同じ思い込みを共有したままになります。
第四に、会話履歴が長くなり、重要な判断と一時的な検討が混ざります。
モデル選択は能力、難易度、影響度で決める
モデルを選ぶ基準は、単純な性能順位ではありません。
不確実性が高く、判断を誤った場合の影響が大きい作業には、深い推論ができるモデルを使います。仕様が確定し、成果物と完了条件が明確な作業には、実装効率のよいモデルを使います。計算ロジックや難しい障害解析には、実装と推論の両方に強いモデルを使います。品質ゲートでは、開発経緯を共有しすぎていない独立モデルを使います。
つまり、最も強いモデルを使い続けるのではなく、仕事に対して過不足のないモデルを選びます。
第7章 Fable・Opus・Sonnet・GPT-5.6 Solの役割設計
以下のモデル名は2026年7月時点で使用した例です。方法論の中心は製品名ではなく、設計、難所実装、量産実装、独立レビューという能力別の役割分担にあります。
Fable――要件、設計、契約、計画を担当する
Fableは、プロジェクトの方向と実装の契約を作る役割に置きました。
主な対象は、要件の構造化、スコープ判定、プロジェクト原則、データ契約、計算仕様、アーキテクチャ、ADR、マイルストーン、タスク分解、ゲートレビュー指摘の裁定、実装結果を踏まえた計画改訂です。
Fableの成果物は、会話のまま実装担当へ渡しません。まずファイルへ固定し、人間が内容を確認します。その後、実装モデルはその文書を正として作業します。
この分離によって、設計判断とコード変更を同じセッションで混ぜずに済みます。実装中に設計の穴が見つかった場合も、実装側で黙って補完せず、契約側へ戻すことができます。
Opus――中核計算と難しい問題を担当する
Opusは、高い推論力と実装力の両方が必要な作業に使いました。
例えば、財務三表の連動、シナリオ間の不変条件、複雑な計算ロジック、テストオラクルの構築、難しいデバッグ、境界条件の整理などです。
すべての実装をOpusへ任せるのではなく、通常実装では解決しにくい部分へ限定します。通常の実装モデルが同じ問題で繰り返し失敗した場合や、実装ではなく設計自体が疑わしい場合にエスカレーションします。
Sonnet――文書化された仕様を正確に実装する
Sonnetは、仕様が確定した後の主力実装を担当しました。
データパイプライン、入力検証、帳票、CLI、テスト追加、境界値対応、レビュー指摘の差分修正など、成果物とDoDが明確な作業を処理します。
Sonnetの効率を高める鍵は、短い指示ではなく、曖昧さの少ない実装契約です。目的、参照文書、入力、出力、非対象、不変条件、必須テストが定義されていれば、不要な再設計をせず実装へ集中できます。
GPT-5.6 Sol――第三者レビューに専念する
GPT-5.6 Solは、コードや仕様を直接修正しない第三者レビュー担当としました。
レビュー対象は、コードの書き方だけではありません。要件と実装の整合、数値モデルの意味、入力境界、成果物間の一致、版管理、再現性、テスト範囲、リリース状態、文書とコードの不一致まで確認します。
レビュー担当が直接コードを直すと、その指摘が正しかったのか、修正が別の問題を生んでいないかが曖昧になります。レビューは指摘と根拠に専念し、主軸側が独立に再現し、採用、却下、先送りを裁定します。
人間――目的、優先順位、判断、承認を担当する
AIモデルを使い分けても、プロジェクトの責任主体は人間です。
どの業務を変えるのか、どの前提を採用するのか、公式数値として扱うのか、どのリスクを受け入れるのか、ゲートを通過させるのかは、人間が判断します。
AIは選択肢、根拠、リスク、検証結果を提示できます。しかし、経営判断や業務責任を引き受けることはできません。
第8章 要件定義から再レビューまでのマルチモデル開発フロー
1. 人間が目的と判断課題を定める
最初に決めるのは機能一覧ではありません。誰が、どの場面で、何を判断できるようにするかです。
2. Fableが要件を構造化する
業務ヒアリング、既存資料、参照製品、データ状況から、要件、未確定事項、調査項目、対象外を整理します。
3. 人間が要件とスコープを確認する
AIが作った要件を、そのまま確定してはいけません。対象企業の事実と一致しているか、期待だけで機能を増やしていないかを確認します。
4. Fableが設計契約を作る
データ型、計算、状態遷移、権限、エラー、リネージ、監査、再実行、承認などを文書化します。
5. 必要に応じてOpusが技術的難所を検証する
計算上の実現性や複雑な境界条件について、小さなオラクルやプローブを使って確認します。
6. Fableが実装計画を作る
機能をマイルストーンと作業単位へ分解し、依存関係、DoD、推奨モデル、ゲート条件を定義します。
7. Sonnetが通常実装を進める
文書化されたタスクを単位として、コード、テスト、成果物を同時に作ります。
8. 難所だけをOpusへエスカレーションする
通常実装で繰り返し失敗した問題や、中核計算、複雑なデバッグを限定的に引き渡します。
9. 実装モデルが自己検証する
テスト、静的検査、実データまたは合成データによるE2E、成果物の目視確認を行います。
10. GPT-5.6 Solが独立レビューする
正典仕様、コード、テスト、実成果物を対象に、第三者として欠陥を探します。
11. Fableが証拠ベースで裁定する
Solの指摘を鵜呑みにせず、実コード、実データ、独立プローブで再現します。採用、却下、先送りと深刻度を決めます。
12. SonnetまたはOpusが裁定済み処方を実装する
修正内容を再び実装契約へ落とし、担当モデルへ渡します。
13. Solが差分再レビューする
修正された箇所と維持すべき不変条件を確認します。既に収束した範囲を毎回全面レビューせず、差分中心へ切り替えます。
14. 人間がゲートを承認する
P0・P1の残存、暫定値、技術条件、業務側条件を確認し、次工程へ進むか判断します。
15. Fableが計画を改訂する
レビューで得た教訓、残課題、新しい事実を仮定台帳と次のマイルストーンへ反映します。
この流れでは、AIが直線的にコードを作って終わるのではありません。設計、実装、独立評価、裁定、修正、承認が循環します。
第9章 実装精度とトークン効率が向上する理由
高度な推論を必要な場所だけに使う
要件の曖昧さを解消する作業、アーキテクチャを決める作業、重大な指摘を裁定する作業には、高度な推論を使う価値があります。一方、仕様が確定したファイル変換、テスト追加、帳票作成まで同じモデルで処理する必要はありません。
モデルの単価だけでなく、手戻りまで含めて考えます。安価なモデルへ曖昧な要求を渡して何度も作り直すより、最初にFableで契約を明確にし、Sonnetへ渡す方が全体として効率がよい場合があります。
タスクに必要な文書だけを渡す
全プロジェクトの資料を毎回読ませるのではなく、タスクの上位文書、対象仕様、関連ADR、DoDを選んで渡します。
タスク指示には、次を含めます。
- 目的
- 参照する正典文書
- 入力と前提
- 実装対象
- 非対象
- 変更禁止範囲
- 期待する成果物
- 必須テスト
- 維持する不変条件
- 完了時に残す証拠
これによってモデルが再設計へ脱線することを防ぎ、必要なコンテキストを小さくできます。
レビュー範囲を段階的に狭める
初回ゲートでは広くレビューします。修正後は指摘箇所、関連契約、回帰不変条件へ範囲を絞ります。いったん収束した範囲は、スコープ変更がない限り差分レビューへ移行します。
これはトークン削減だけでなく、レビューを終わらせるためにも重要です。毎回すべてを再レビューすれば、新しい軽微な論点が無限に見つかり、ゲートが収束しません。
文書がAIの記憶を外部化する
AIセッションは永続的なプロジェクト記憶ではありません。決定を文書、ADR、仮定台帳、引継ぎ、レビュー記録へ外部化することで、モデルが変わっても同じ契約から再開できます。
この外部記憶があるから、各AIへ必要な役割だけを任せられます。マルチモデル開発は、モデルを増やすことではなく、文書によって複数のモデルを一つのプロジェクトへ接続することです。
従来は現実的でなかった開発密度
これまでも、十分な予算と人員があれば、詳細な要件定義、設計、実装、テスト、独立レビューを行うことはできました。しかし、小規模チームや短期間のプロジェクトで、それらを高い密度で反復することは難しかったです。
マルチモデルAI開発では、次の作業を短いサイクルで行えます。
- 大量の業務資料を構造化する
- 複数の設計選択肢を比較する
- 設計契約とDoDを文書化する
- 仕様に沿ったコードとテストを同時に作る
- 実成果物を独立AIがレビューする
- 指摘を証拠ベースで裁定する
- 修正後に再レビューする
- 教訓を次の実装計画へ即座に反映する
これは「AIが人間を不要にした」という意味ではありません。少人数でも、従来より多くの専門的な作業を同時に維持できるようになったという意味です。
第4部 中長期経営計画モデルで実践する
第10章 経営判断と計算を分離する
中長期経営計画モデルでは、計画策定、年度展開、振り返り、ローリングを支える仕組みを段階的に構築しました。
システムには、市場データの取得、事業別ドライバー、シナリオ、財務三表、感応度、ポートフォリオ、投資ステージゲート、帳票、管理会計システムとの接続など、多くの要素があります。
複雑なモデルを一度に作ろうとせず、基盤、ワークショップ用プロトタイプ、全事業と三表の連動、中計数値パッケージ、ローリング運用というマイルストーンへ分割しました。各マイルストーンにはDoDとゲートを設定しました。
前提とロジックを分離する
経営陣が変更する前提はYAMLへ集約し、計算ロジックはテスト付きPythonへ置きました。シナリオを追加するときは前提ファイルを追加し、モデルコードへ個別条件を書き込みません。
仮定値には、出典、暫定であること、確定予定、影響範囲を持たせます。取得できない外部データをAIが推測して埋めることは禁止しました。
この分離によって、同じロジックで複数シナリオを比較できます。前提を変えた場合に、どの結果が変わるべきかもテストできます。
数値をLLMに計算させない
計画数値、財務三表、シナリオ差、感応度は、すべて決定論的なコードで計算します。LLMはコードや説明文を作りますが、帳票へ載せる数値を暗算や文章生成で補完しません。
計算モジュールには、小さなデータで正解を固定するテストオラクルと、合計保存、BS一致、CF整合などのプロパティテストを用意しました。
これにより、AIを使って開発しても、経営数値の正しさをAIの言語能力へ依存させずに済みます。
公式数値と判断は人間が承認する
モデル出力は、承認されるまでドラフトです。海外展開や新技術投資のステージゲートも、モデルは判断材料を提示するだけで、継続・撤退を自動決定しません。
これは責任の分離です。AIとモデルは、計算と論点整理を高速化します。最終的な経営判断は、前提、リスク、現場情報を踏まえて人間が行います。
モデル別の役割分担を実際に適用する
Fableは、全体プロセス、仮定台帳、計算契約、帳票契約、マイルストーン、レビュー裁定を担当しました。
Opusは、難しい計算ロジック、財務三表、オラクル、複雑な修正を担当しました。
Sonnetは、外部データパイプライン、各事業ドライバー、帳票、入力検証、テスト追加などを担当しました。
GPT-5.6 Solは、各マイルストーンで、コード、仕様、テスト、生成帳票を第三者として確認しました。
この役割分担は、単なる作業分担ではありません。設計者、実装者、レビュー担当の視点を分離し、同じ思い込みが全工程を通過することを防ぐ仕組みです。
第5部 第三者レビューと品質管理
第11章 AIによる第三者レビューを品質ゲートへ組み込む
テストが通ることと、正しいシステムであることは同じではない
自動テストがすべて通っていても、テストが確認していない契約は存在します。
実際のレビューでは、効果を計上する一方で必要な投資が計算へ入っていない、重要入力が版管理用ハッシュから漏れている、不正な実績値を入力境界で拒否できない、同じ指標が複数帳票で異なる、コードと正典仕様で意味が逆転している、といった問題が発見されました。
これらの多くは単純な文法エラーではありません。実装されたロジックの内部では整合していても、上位の業務契約や成果物全体から見ると欠けている問題です。
独立レビューの基本サイクル
レビューは次の流れで行いました。
- 主軸AIが実装と自己検証を完了する
- レビュー対象の仕様、コード、テスト、成果物を固定する
- GPT-5.6 Solが第三者レビューを行う
- Fableが各指摘を独立に再現する
- 採用、却下、先送りと深刻度を決める
- 修正用の契約とDoDを作る
- SonnetまたはOpusが修正する
- Solが差分を再レビューする
- P0・P1の残存を確認する
- 人間がゲートを承認する
指摘を鵜呑みにしない
第三者AIの指摘にも、誤読や過剰評価の可能性があります。そのため、指摘文だけで採否を決めません。
実コードを読み、実成果物を確認し、最小の入力変異を与え、独立に再現します。指摘より広い問題が見つかる場合もあれば、実害の範囲が限定される場合もあります。
レビュー担当と裁定担当を分けることで、レビューAIの権威に依存せず、証拠に基づく品質管理ができます。
深刻度とゲート条件
指摘は、例えば次のように分類できます。
- P0：数値誤り、情報漏えい、破壊的処理など、直ちに止める問題
- P1：ゲート通過前に必ず直すべき契約違反
- P2：条件と期限を明記して先送りできる問題
- P3：改善候補や保守性上の助言
P0・P1が残る状態ではゲートを通しません。P2を先送りする場合は、期限、発動条件、次に確認する場所を記録します。
再レビューを収束させる
レビュー品質を高く保つことと、レビューを永遠に続けることとは異なります。
初回レビューは広く、再レビューは差分と関連契約へ集中します。収束した範囲は、スコープ変更がない限り再び全面レビューしません。軽微な課題は次のゲートへ条件付きで送ります。
ゲートとは完全無欠を宣言する場ではありません。重大なリスクを閉じ、残存課題を可視化し、人間が次へ進む判断をする場です。
第12章 生産性とトークン効率を記録で測る
Vibe Codingの生産性を伝えるとき、「体感で速い」だけでは説得力が弱いです。一方、単純なコード行数やテスト数も、価値を正確には表しません。
今後は、少なくとも次を記録することが望ましいです。
- 日付と作業単位
- 要件、設計、実装、レビューの区分
- 使用モデル
- 実作業時間
- 入出力トークン
- 完了した成果物
- 追加したテスト
- 初回で完了したか
- 再作業の回数と理由
- レビューで見つかった有効指摘
- 人間が判断した事項
特に、トークン効率は単純な使用量だけで評価しません。高性能モデルを設計に使った結果、実装の手戻りが減ったのであれば、その設計トークンには価値があります。逆に、安価なモデルを使っても、曖昧な指示で何度もやり直せば全体効率は悪くなります。
評価すべきなのは、承認可能な成果物を得るまでの総コストです。
現時点で作業時間やモデル別の実績ログが残っている場合でも、外部へ「何倍速い」と示すには比較条件を揃える必要があります。対象範囲、人間の確認時間、レビュー時間、未完成部分、従来開発の比較基準を明記します。
誇張した数字より、どの工程をどう変えた結果、どの作業が短縮されたかを具体的に説明する方が、読者にとって再利用しやすいです。
第6部 再現可能な方法として持ち帰る
第13章 業務Vibe Codingの落とし穴
要件が曖昧なまま実装へ進む
AIは曖昧な要求からでもコードを作れます。そのため、要件不足が見えにくいです。動く画面が早くできるほど、正しいものを作っているように感じる危険があります。
一つのモデルへ全工程を任せる
設計、実装、レビューを同じモデルと会話で続けると、同じ前提を共有したままになります。独立レビューの効果が弱くなります。
高性能モデルを単純実装にも使い続ける
高度な推論が必要な場所と、仕様どおりに作る場所を区別しないと、トークンとコストを浪費します。
軽量な実装モデルへ曖昧な指示を渡す
モデルの効率は、指示と設計の品質に大きく依存します。要件の穴を実装モデルの推測で埋めさせてはいけません。
モックと本番を混同する
画面が動くことと、権限、監査、再実行、異常系、バックアップ、運用が成立することとは異なります。
テスト件数を品質そのものと考える
大量のテストがあっても、間違った契約をテストしている可能性があります。業務意味、入力境界、実成果物、文書整合を別途確認します。
LLMに数値や根拠を補完させる
取得できない数値を推測で埋めると、もっともらしい経営資料ができてしまいます。N/A、暫定、出典不明を正直に表示します。
先回りして汎用化する
二社目の具体的要件がない段階で、あらゆる会社に対応する設定基盤を作りません。境界は保ちながら、まず一社の実問題を解きます。
文書とコードがずれる
コードだけを修正すると、次のAIが古い文書を読み、問題を再導入します。契約、コード、テスト、帳票を同じ変更として扱います。
AIの指摘を無条件で採用する
レビューAIも間違えます。独立再現と裁定が必要です。
人間の判断をAIへ委ねる
AIは判断材料を作りますが、業務責任、投資判断、公式承認を担いません。
第14章 マルチモデルAI開発の実践プレイブック
Step 1 対象業務と支援する意思決定を定める
誰が、いつ、何を判断するためのシステムかを書きます。
Step 2 短期間でモックを作る
業務フローを触れる形にし、認識差と未確定事項を見つけます。
Step 3 要件調査で仮説を検証する
質問、回答、根拠、確定、暫定、未確認を分けます。
Step 4 スコープと絶対原則を固定する
作るもの、作らないもの、AIに任せないものを明示します。
Step 5 データ・業務・計算の契約を作る
入力、出力、型、状態、権限、例外、履歴、承認を定義します。
Step 6 マイルストーンとDoDを設計する
各段階で何を確認できれば次へ進むかを先に決めます。
Step 7 タスクを分類する
不確実性、技術難易度、影響度、物量、独立性で分類します。
Step 8 モデルを割り当てる
- 要件、設計、計画、裁定：Fable
- 中核計算、難しいデバッグ：Opus
- 文書化済み仕様の実装：Sonnet
- 独立レビュー：GPT-5.6 Sol
- 目的、判断、承認：人間
Step 9 文書を介して引き渡す
会話ではなく、正典文書、タスク契約、DoD、引継ぎを使います。
Step 10 レビュー、裁定、修正、承認を行う
独立レビューを品質ゲートへ組み込み、結果を次の計画へ戻します。
第15章 文書によって全体と各タスクをコントロールする
文書は名称ではなく、制御したいものから設計する
必要なのは「要件定義書という名前のファイル」ではありません。何を制御するための情報かを明確にすることです。
目的と成功条件を制御する
この文書は、なぜ作るのか、誰のどの判断を支援するのか、成功をどう測るのかを固定します。
スコープと原則を制御する
対象、非対象、優先順位、絶対原則、AIに任せないこと、共通と個社の境界を固定します。
要件と未確定事項を制御する
業務上の質問、回答、根拠、確定・暫定・未確認、追加調査、当初仮説との差分を管理します。
アーキテクチャと実装境界を制御する
データの流れ、責務、接続方式、計算と判断の分離、障害時の挙動、正典成果物を決めます。
マイルストーンと依存関係を制御する
作業順序、前提条件、DoD、ゲート、持ち越し、ユーザー判断を管理します。
個々のタスクを実装契約で制御する
タスクには最低限、次を持たせます。
- タスクの目的
- 参照する上位文書
- 入力データと前提
- 実装対象
- 変更してよい範囲
- 変更してはいけない範囲
- 非対象
- 期待する成果物
- Definition of Done
- 必須テスト
- 維持すべき不変条件
- エラー時に停止する条件
- 完了時に残す証拠
- 推奨モデル
- エスカレーション条件
- 次工程への申し送り
判断と変更を制御する
判断理由、代替案、採用しなかった案、承認者、前提、再判断条件をADRや決定記録へ残します。
仮定と暫定値を制御する
仮定の内容、出典、暫定か確定か、影響範囲、確定予定、差替方法、ゲートへの影響を台帳化します。
品質とゲートを制御する
実行したテスト、確認した成果物、基準値、再現手順、指摘、深刻度、裁定、修正条件、承認を記録します。
セッション間の引継ぎを制御する
完了事項、未完了事項、現在の正典仕様、変更ファイル、実行済みテスト、残存リスク、次の作業を残します。
文書間の上下関係を制御する
どの文書が仕様の正か、衝突時に何を優先するか、誰が更新するか、どの変更に承認が必要かを決めます。
文書を循環として運用する
文書は次の流れでつながります。
構想・原則
→ 要件・スコープ
→ 設計契約
→ 実装計画
→ タスク分解・モデル割当
→ 実装・テスト
→ 第三者レビュー
→ 裁定・承認
→ 仕様・計画改訂
→ 次のタスク
規模に応じた最小構成
小さなモックでは、目的、対象範囲、画面フロー、未確定事項、非対象があれば十分です。
本番指向の業務アプリでは、これにプロジェクト原則、データ契約、権限、監査、実装計画、受入条件、セキュリティレビューを加えます。
経営管理や計算モデルでは、さらに仮定台帳、計算仕様、テストオラクル、リネージ、ADR、ゲートレビュー、承認記録、工数ログが必要になります。
文書を多く作ることが目的ではありません。必要な判断と契約を、次の人間とAIが迷わず使える状態にすることが目的です。
第7部 公開し、社会へ還元する
第16章 公開・再利用するときのマスキングとガバナンス
企業の事例を公開する場合、会社名だけを置き換えれば安全とは限りません。
次の情報を確認する必要があります。
- 企業名、ブランド名、取引先名
- 個人名、メールアドレス、ユーザー名
- 実際の財務数値、件数、利益率、人員数
- 内部システムや進行中プロジェクトの名称
- 導入予定、契約予定、将来日程
- ローカルパス、URL、環境名
- APIキー、アカウント、クラウド情報
- コミットID、承認履歴
- 顧客固有の業務ロジック
- 帳票やスクリーンショット内の実データ
- 複数情報を組み合わせると企業を特定できる記述
公開用には、架空企業、合成データ、一般化した業務フローを使います。社内の正典文書から直接公開するのではなく、公開版を別に作り、マスキングレビューを行います。
また、モデル名、料金、性能、利用条件は変わります。具体的な名称には執筆時点を付け、方法論の部分は「設計担当」「難所実装担当」「量産実装担当」「独立レビュー担当」のように一般化します。
公開の目的は、内部情報を示すことではありません。どのように問題を分解し、どのようにAIと人間を配置し、どのように品質を管理したかを共有することです。
おわりに Vibe CodingからマルチモデルAI開発へ
Vibe Codingは、思いついたものを短時間で動かす強力な方法です。ゲームやモックでは、その速さ自体が大きな価値になります。
しかし、業務システムでは速さだけでは足りません。要件が正しいこと、計算が再現できること、前提と根拠が追跡できること、異常な入力を止められること、人間の承認が残ることが必要です。
この水準へ進むために有効だったのが、工程とAIモデルの分離でした。
Fableが要件、設計、契約、計画を作ります。Opusが中核計算と難しい問題を担当します。Sonnetが文書化された仕様を正確に実装します。GPT-5.6 Solが第三者として欠陥を探します。Fableが指摘を裁定し、人間が最終判断と承認を行います。
そして、これらをつなぐのが文書です。
文書は完成後に作る説明資料ではありません。人間とAIの認識を揃え、複数モデルへ必要なコンテキストだけを渡し、タスクを制御し、レビュー基準を提供し、次のセッションへ記憶を引き継ぐ開発基盤です。
重要なのは、最も強いAIモデルを使うことではありません。目的、リスク、難易度に応じて複数のAIを編成し、文書によって仕事をつなぎ、人間が判断と承認を握ることです。
それによってVibe Codingは、速い試作から、精度、説明責任、再現性を備えた業務システム開発へ進化します。
コメント