AI 原生開発の真髄：コーディング以外でのプロセス変化を事例から解説

多くの人が「AI を使ってコードを書かせる」ことだけを AI 開発と捉えています。

これは間違いではありませんが、不十分です。コーディングはソフトウェア開発プロセスの一部に過ぎず、AI 時代においてはむしろ変化が少なく、最も心配する必要がない部分になりつつあります。なぜなら、現在の大規模言語モデル（LLM）はコード生成においてすでに高度な訓練を積んでおり、単純な自然言語の指示だけで十分な成果を得られるからです。

真に変化しているのは、コードの外側です。要件分析や設計、プロトタイピング、テストの実施など、「コーディング以外の工程」こそが、AI 原生開発がゲームチェンジャーとなる場所なのです。

先日、私は AI を活用して自身のアプリに新機能を追加しました。このプロセスは非常に典型的な例であり、その全体像を振り返る価値があります。

結論：プロセスは変わらず、役割が変わった

事例に入る前に、最も重要な認識をお伝えします。

AI 原生開発の本質は、依然として従来のソフトウェア開発プロセス——可行性分析（実現可能性の検討）、設計、プロトタイピング、コーディング、テスト検証——を踏襲しています。これらのステップが欠けることはありません。

変わっているのは「誰が実行するか」という点です。

以前は各工程を人間が手作業で行っていましたが、現在は人間が指揮官となり、エージェント（Agent）が実行役となります。人間は重要なパス上で確認と意思決定を行うのみで、具体的な分析、設計、コーディング、デバッグのすべてをエージェントに任せるのです。

例えて言えば、あなたは現場のプログラマーから技術総責任者へと昇格したようなものです。すべての行を直接書くわけではありませんが、「やるべきか」「どのように行うか」「正しくできているか」を決めるのはあなたです。

一見すると大したことないように思えるかもしれません。しかし、実際にこの一連のフローを完走させてみると、その効率化は桁違いであることがわかります。

要件はどこから来るのか

今回の新機能は、GitHub の Issue に端を発しています。私の字幕トランスクリプト翻訳アプリ「BaoCut」に対して、あるユーザーから「遠隔でのトランスクリプト実行機能を追加してほしい」という要望が寄せられたのです。

具体的なシナリオは以下の通りです。ユーザーは高性能な計算資源を持つパソコン A と、日常業務用のパソコン B を持っています。パソコン B で BaoCut を利用する際、計算リソースを要するトランスクリプト処理をパソコン A に任せて実行したいと考えていました。

私は直感的に、これは素晴らしい要望だと感じました。シナリオが具体的であり、ユーザーにとって価値があり、製品の方向性とも合致しているからです。

しかし、すぐにエディタを開いてコーディングを始めたわけではありません。

第一関門：実現可能性分析——やるべきかを決める

この工程は、プロセス全体の中で最も省略されがちですが、決して飛ばしてはいけない最重要ステップです。

「まずやるべきかを考え、その上で実行する」。これは一見すると当たり前の話に聞こえるかもしれませんが、私はこれによって多くの失敗を味わってきました。

先日のことでは、ローカルで動作するテキストモデルを活用して字幕の分割とアライメントを補助する機能を実装しました。実現可能性分析の段階では技術的な問題はないと考えましたが、実際に実装して体験してみると、その品質は極めて低く、結局は機能を削除することになりました。数日間の時間と大量のトークンが浪費されたのです。

このように、実現可能性分析を行っても判断を誤ることはあります。しかし、それは分析自体が無意味だということではありません。逆に、このステップを省けば、より深刻な罠に陥る可能性が高まるのです。

これは期待値に基づく賭けです。多くの場合、この分析が近道への回避役として機能し、稀に判断を誤ることはあっても、全体としては大きな損失を防いでくれます。

実現可能性分析では通常、以下の 2 つの側面を確認します。

• 製品側の視点: この機能には価値があるか？アプリの方向性と整合しているか？
• 技術側の視点: 技術的に実装可能か？コストはコントロールできる範囲内か？

今回のケースでは、製品側についてはすでに「実施する価値あり」と判断済みでした。そのため、私は技術的な実現可能性に焦点を絞って検討を進めました。

まず、ユーザーからの原始ニーズを Claude Code に投げ、プロジェクトの現状を踏まえた可行性分析を行わせます。その結果、実現可能という判断が下され、いくつかの技術案が提示されました。

私はこれらの案を素早く確認し、即座に独自の判断を下しました。

• 案 0 と案 C はコード変更が不要ですが、ユーザー体験が悪く、ASR サーバーの独自構築が必要となるため、一般ユーザーにはハードルが高すぎます。
• 案 A が最良です。アプリをインストールするだけでトランスクリプションサービスを開始できるため、ユーザーにとって最もシンプルです。
• 案 B は Windows 環境への対応が不十分です。

というわけで、案 A をベースに推進し、同時に案 0 で提案されていた「HTTP トランスクリプション API の提供」という付加機能も盛り込むことにしました。

ここで重要なのは、この作業フローの模式です。Agent が分析を行い複数の案を列挙し、人間が最終的な判断を下すという役割分担です。これが「重要なパスにおける人間の確認」の意味するところです。各技術案の詳細を自分で調べる必要はありませんが、製品としての視点と技術的直感に基づいて最終決定を下す必要があります。

第二関：設計ドキュメント——Agent をつなぐ架け橋

実現可能性と技術方向性が確定したからといって、すぐにコーディングに入るわけではありません。次のステップは、Agent に設計ドキュメントの作成を依頼することです。

なぜドキュメントが必要なのか？ここには AI ネイティブ開発における重要な認識が関わっています。

AI の時代において、ドキュメントは人間と Agent、そして Agent と Agent をつなぐ新たな役割を果たすようになります。

従来の開発プロセスでは、ドキュメントは完成後にすぐに陳腐化し、作成者も閲覧者も負担に感じる存在でした。しかし AI ネイティブ開発においては、ドキュメントが最も重要な中間媒介へと変貌します。その理由は主に二つあります。

第一に、ドキュメントは人間による確認と修正のための媒体です。Agent が作成した案をドキュメントとして出力すれば、人間はそれを読み込み、方向性が正しいか、詳細に問題がないかをチェックし、直接ドキュメント上で修正を加えることができます。

第二に、ドキュメントは Agent のセッション間でコンテキスト（文脈）を伝達する媒体です。各 Agent セッションのコンテキストウィンドウには限界があります。「設計」フェーズから「開発」フェーズへ移行する際、多くの場合で新しいセッションが開始されます。前のセッションでの思考プロセスや意思決定の根拠、技術的な選定結果などは、ドキュメントを通じて次のセッションに引き継がれる必要があります。ドキュメントが存在しなければ、次のセッションはゼロから始めなければなりません。

言い換えれば、ドキュメントとは AI ネイティブ開発における「記憶の担い手」なのです。

私がここで作成させたのは、製品設計と技術設計を融合したドキュメントです。具体的な要求事項、アーキテクチャの設計方法、インターフェースの定義などを明確に記述します。目的は、これらの情報を固定化し、後続の実装を担当する Agent に明確な指針を与え、人間側にも方向性を検証できる拠点を確保することです。

理想的な状態では、各フェーズの終了時には、要件定義書、設計案、プロトタイプ、コード、テスト結果といった、アーカイブ可能な成果物を生成すべきです。さらに、これらすべての成果物を git などのバージョン管理ツールと連携させ、変更履歴をすべて追跡可能にします。そうすることで、これらのドキュメント自体が監査記録としても機能します。「誰が要件を提出し」「Agent が何を出力し」「誰が承認したか」を明確に記録できるのです。

今回は少し手を抜いて、設計ドキュメント作成後に直接プロトタイプ制作に移りました。前段階の可行性分析で提示された案に問題がなく、Fable 5 への信頼も厚かったからです。ただし、より複雑なプロジェクトでは、設計ドキュメントを精査することが不可欠です。コードを書き上げてからやり直すコストと比べれば、この工程にかかるコストは圧倒的に低いです。

ここで重要な操作ポイントがあります。承認されたドキュメントこそが、次の Agent Session における完全な起点となるということです。「設計」フェーズから「開発」フェーズへ移行する際は、多くの場合新しいセッションを開始します。その際、Agent に背景事情を改めて説明する必要はありません。単に「docs/remote-transcription.md に従って実装してください」と指示するだけで十分です。ドキュメントにはすべての意思決定と詳細が記述されていますので、新しい Session でそれを読み込めば即座に実行に移せます。

第三関：高精度プロトタイプ設計——要件・プロトタイプ・UI の一体化

このステップこそ、AI ネイティブ開発において最も劇的に変化した部分の一つだと私は考えています。

従来のワークフローでは、要件定義書、プロトタイプ設計、UI デザインはそれぞれ独立した工程であり、担当も異なります。产品经理（製品マネージャー）が要件を書き、インタラクションデザイナーがプロトタイプを作成し、UI デザイナーが視覚デザインを担当します。各工程の引き継ぎには必ず情報ロスが発生し、修正を行う際にも関係者間の調整が必要でした。

しかし AI の力を借りれば、これら三つを一つの工程に統合できます。それが「高精度プロトタイプ設計」です。つまり、作成するプロトタイプは単なるワイヤーフレームではなく、最終製品に近い高忠実度（High-Fidelity）のデザインとなります。そこにはインタラクションロジックと視覚デザインが直接組み込まれています。

以前はこの手法は現実的ではありませんでした。コストが高すぎるからです。製品思考、インタラクション設計、UI デザインのすべてを一人が兼ね備えることは難しく、仮にそのような人材がいたとしても、高忠実度プロトタイプを作成するには数日かかるのが普通でした。しかし現在では、AI Agent と優れた Design Skill（特におすすめなのは Claude Design です。私の baoyu-design も利用可能です。会話で「原型設計」と指示するだけで自動的にトリガーされます）を組み合わせることで、高精度なプロトタイプを短時間で生成できるようになりました。

私のアプリには、これに付随するプロトタイプ設計ページがあります。機能の追加や修正があるたびに、まずこのプロトタイプを更新します。設計ドキュメントを基礎としているため、プロトタイプ制作は比較的スムーズに進み、最初のバージョンでも良好な結果が得られました。設定画面に新しいタブを追加し、転写サービスの起動やネットワーク上の他ノードの発見といった機能を実装したのです。

しかし、プロトタイプができあがったからといって完了ではありません。プロトタイプ設計段階での修正コストは相対的に低く抑えられますが、実際に製品化してから変更を加えるのは非常に高価になります。そのため、この工程には時間をかけて繰り返し磨き上げる価値があります。

私はプロトタイプ上で何度も調整を繰り返しました。まずはレイアウトをリスト形式からタブ形式に変更し、「サービスの起動」と「他ノードへのアクセス」を分離しました。これらは別々のユースケースであり、混在させるとユーザーが混乱すると考えたからです。また、サービス状態を示すアイコンを追加し、ユーザーが一目でサービスがオンかオフかを把握できるようにしました。

その後、この機能を設定画面に配置するのは不便だと気づきました。ユーザーはサービス状態を頻繁に確認する必要があるため、深く埋め込まれた設定ページでは使いにくいのです。そこでメイン画面へ移すことにしました。何回もやり直しを繰り返した結果、ようやく満足できる形になりました。

ここで重要なのは、この作業プロセスです。変更したい内容を自然言語で指示するだけで、Agent がプロトタイプを修正してくれます。私の注力は「そのインタラクションは使いやすいか」「画面デザインは魅力的か」「ユーザーが違和感なく使えるか」といった製品側の判断に集中できます。ピクセル単位の調整やレイアウトの実装細節に悩む必要はありません。

なぜプロトタイプの確認ステップを省略すべきではないのか？ 一度開発が完了すると、界面とインタラクションの修正コストは指数関数的に跳ね上がります。コードロジックの変更だけでなく、スタイル管理、ステート管理、テストケースまで全て書き換えなければなりません。しかしプロトタイプ段階では、レイアウトの変更は一語で済むこともあります。

第四關：実装——コードがボトルネックではない

ここまで来れば、設計ドキュメントと承認済み的高精度プロトタイプが手元にあります。現在のモデルにとって、Agent にコードを書かせるのは非常に簡単な作業です。

/goal コマンドを使って、設計ドキュメントとプロトタイプを Claude Code（Fable 5）に渡します。ドキュメントで計画されたマイルストーンに従って一つずつ実装していきます。Agent は実装順序を自ら规划し、コードを書き、テストを実行し、結果のスクリーンショットを取得して検証まで行います。

ここでよく見逃されがちですが、私が常に強調しているポイントがあります：Agent に自己検証させることで、人間の介入回数を減らせます。 コードを書き終えたら自動的にテストを実行し、失敗すれば自分でデバッグして修正します。画面を変更したら自らスクリーンショットを取得して効果を確認します。つまり Agent 自身にフィードバックループを持たせ、人間が結果を確認する前に一度自分自身でチェックさせるのです。こうすることで、最終確認時に手元に来るのは粗末な初稿ではなく、Agent が自分で検証済みの成果物になります。

そのため、いくつかの確認工程を統合（例えばコードレビューをスキップして直接ブラックボックステストを行う）しても比較的安全です。Agent 自身の能力が十分であり、開発過程で自己検証を行っているため、出力品質は非常に高くなります。

この段階で人間が行う作業は極めて少なく、主に待機し、時々進捗を確認する程度です。

よく考えてみると、コード自体はもうボトルネックではありません。従来のプロセスでは PRD（製品要件定義）、見積もり、セキュリティ審査などは開発前に調整を行うためのものでした。なぜなら開発には数週間から数ヶ月かかるからです。しかし Agent が数時間でコーディングを完了できる時代になり、これらの確認フローは AI 時代に再考する必要があります。

ボトルネックはコードの両側に移動しました：左側が設計と確認、右側がテスト・検証・デプロイです。 これらの工程はまだ人間の速度で進行しており、現在最適化すべきポイントです。

だからこそ、私は前回の可行性分析、設計ドキュメント、プロトタイプ作成にこれほど多くのページを割いたのです。AI 原生開発において、「コード以前」の作業こそが最も重要だからです。

第五關：テスト——一般ユーザーになりきる

Agent がテスト作成や実行、結果検証を代行してくれるからといって、すべてを丸投げしてはいけません。最終的には自分自身で試す必要があります。

ここで最も重要なのはマインドセットの転換です。開発者ではなく、一般ユーザーとして振る舞うことが求められます。

開発者の視点とユーザーの視点ではテストの質が全く異なります。開発者は無意識に境界条件を避け、自分が想定した通りのパスで操作してしまいがちです。しかし一般ユーザーはそうではありません。彼らは適当にクリックしたり、予期せぬ入力を行ったり、あなたが想像もしていない方法で機能を使ったりします。

したがって、行うべきことはこうです：アプリを開き、その機能を初めて見たかのように振る舞い、直感に従って操作してみましょう。メッセージは十分明確か、インタラクションは自然か、エラー時には適切な誘導があるかをチェックしてください。

発見した問題はそのまま Agent に投げつけ、修正させます。数回のやり取りを繰り返せば、機能は実用レベルに達します。

完成品を見てみましょう。遠隔トランスクリプション機能はすでに完全に動作する状態になっています。

コードレビューは行ったか？と聞かれるかもしれませんが、いいえ、行っていません。私は QA 担当として黒箱テストのみを実行し、Fable 5 のコーディング能力を信頼しました。これは前述の「マージ確認」プロセスの具体例でもあります。Agent は開発過程で自らテストを実行し、スクリーンショットによる検証も済ませており、そこにユーザー視点からの黒箱テストをもう一度加えることで、十分な二重チェックが完了します。

もちろん、この判断はプロジェクトの重要度によります。金融システムの核心ロジックなどであれば、やはりコードレビューが必要になるでしょう。しかし、多くの機能開発においては、黒箱テストだけで十分です。

本質的な変化：何がどう変わったのか？

振り返ってみると、全体のプロセスは以下の通りです。

可行性分析 → 设计文档 → 原型设计 → 编码实现 → 测试验证

これは従来のソフトウェア開発プロセスと何ら変わりありません。その通りです。

AI ネイティブ開発とは新しいプロセスを発明したのではなく、既存のプロセスを新たな方法で実行するものです。

具体的には、3 つの本質的な変化があります。

変化 1：実行主体が「人」から「Agent」へ

各工程において、実際に作業を行うのは Agent です。自分で実行可能性分析を作成する必要も、プロトタイプを描く必要も、コードを書く必要も、テストケースを作成する必要もありません。重要なのは、主要なノードで確認と意思決定を行うことです。

人間の役割は判断と意思決定に集中し、Agent が実行と細部の処理を担当します。

変化 2：確認工程の統合は可能だが、省略は不可

従来のプロセスでは、要件確認、プロトタイプ確認、UI 確認はそれぞれ独立したレビュー会議として行われていました。しかし現在はこれらを統合できます。要件定義書、プロトタイプ設計、UI 設計を一体化させた高精度なプロトタイプを作成し、一度に確認することが可能です。設計ドキュメントとプロトタイプ設計も併せて確認できます。

ただし、確認工程そのものを省略することは絶対にできません。 各確認工程には明確な存在意義があります：

• 実行可能性の確認：まず「やるべきか」を決定し、無駄な作業に時間を費やさないようにする
• 技術方針の確認：選択した方向が最適かどうか、より良い代替案がないかを検討する
• プロトタイプ/UI の確認：インタラクションは使いやすく、UI は見やすいか。完成後に修正するのはコストが高く、プロトタイプ段階なら修正が容易である
• テストの確認：開発者視点で「動くか」を検証するのではなく、ユーザー視点で「使いやすいか」を検証する

確認を加速させる（工程を統合し、プロセスを簡素化する）ことは可能ですが、確認そのものをスキップすることはできません。人間の判断力は、このプロセスにおいて代替不可能な要素です。

変化 3：ドキュメントの重要性がさらに高まる

従来の開発ではドキュメントは付随的なものであり、コード完成後に後付けされるか、あるいは作成されないことさえありました。しかし AI ネイティブ開発においては、ドキュメントが中核インフラストラクチャへと昇格します。

それは以下の 2 つの重要な機能を果たします：

• 人間による確認と修正のための媒体：設計ドキュメントの審査、プロトタイプへのコメント追加、技術方針の修正など、これらの作業はすべてドキュメント上で行われます。

Agent の各セッション間でコンテキストを共有し、設計ドキュメントは開発用セッションへ、プロトタイプは実装用セッションへと引き継がれます。これにより、各セッションは孤立することなく連携できるようになります。

Claude Code を使ったことがある方なら、この点に深く共感できるでしょう。新しいセッションを開くたびに、これまでのコンテキストを改めて説明する必要がありました。しかしドキュメントこそが最適なコンテキスト伝達媒体です。口頭での説明よりも正確であり、チャットログよりも構造化されています。

ただし、ドキュメントにも新たな課題があります。バージョン管理が追いついていない場合、逆に誤ったコンテキストを伝えてしまうリスクがあるのです。

Skills に関する直感に反する視点

最後に、多くの方が関心を持つ「Skills をどう使うか」という話題について触れましょう。Agent のコーディング能力を強化するために、多くの開発系 Skills を導入すべきでしょうか？

私の答えは意外なものでしょう。開発系の Skills は大部分が不要です。

現在の大規模言語モデルはコーディングにおいてすでに極めて高い性能を発揮しています。私が Agent と行った会話を見ても、非常にシンプルな自然言語の指示のみでした。「実現可能性を分析してほしい」「案 A に基づいて設計ドキュメントを作成して」「この設計でプロトタイプを作って」「ドキュメントに従って実装して」。複雑なプロンプトエンジニアリングも、特別なコーディングスキルも必要ありませんでした。

前述した通り、ボトルネックはコードの両側に移っています。コードそのものには強化の余地がなくなり、強化すべきは左側の設計確認と、右側のテスト検証・デプロイです。

私が実際に使っているのは、この 2 つのボトルネックに対応する 2 種類の Skills のみです。

第一類：設計確認を支援するもの（左側ボトルネック対策）

Claude Design や baoyu-design といったツールが該当します。これらはプロトタイプ作成と UI デザインを一体化したもので、コードを書く前に画面やインタラクションを確認できるため、高精度なプロトタイプを迅速に生成できます。

第二類：自動化で人的労力を減らすもの（右側ボトルネック対策）

自動デプロイや自動リリースなどがこれに当たります。コーディング完了後のパッケージ化、デプロイ、リリースといった工程は判断力を要しませんが、時間がかかります。また /goal といったコマンドを使えば、Agent がマイルストーンに従って自動的に進行し、タスクの手動分割作業を減らせます。

真ん中の層である「コーディングそのもの」については、モデルの性能が十分です。シンプルな指示で高品質なコードが得られます。プロンプト最適化に時間を割くよりも、プロセス設計に注力する方がはるかにリターンが大きいです。

おわりに

この機能の開発を振り返ると、GitHub Issue から完全な動作まで、コーディング自体にかかる時間はほとんどありませんでした。最も時間を要したのは、実現可能性の判断、プロトタイプの反復的な磨き上げ、そしてテスト時に自分自身を初心者のように振る舞って試行錯誤することです。これらはまさに Agent には代替できない部分です。「やるべきか」「方向性が正しいか」「使いやすさ」——これらの最終決定はすべて人間が行わなければなりません。

AI ネイティブ開発の真髄もここにあります。開発プロセス自体は従来と変わりませんが、人間の役割が変わったのです。コードを書く人から、Agent を管理する人へ。成果物也不再はコードではなく、一連の判断と意思決定です。

コードへの執着を手放すのは容易ではありません。特に長年コードを書いてきた方にとって、すべての行を確認せずにマージするのは不安に感じるでしょう。私も「ブラックボックステストのみを行う」状態に至るまで、段階的に歩んで来ました。しかし趨勢は明確です。モデルのコーディング能力はさらに向上し、人間の価値はコードの両側に集中していきます。この役割転換を早く行うほど、AI から得られるレバレッジは大きくなります。