AI駆動開発とは｜3つのレベルとメリット・デメリット、導入7ステップ

伝言ゲームというのは、残酷な遊びだと思います。

小学校でやったとき、最初の文と最後の文がまったく違いました。 誰も嘘をついていません。一人ひとりが、聞こえたとおりに伝えただけです。

面白いのは、途中の誰かが「たぶんこういう意味だろう」と整理した瞬間に、大きく変わることでした。整理した人がいちばん親切だったのに、いちばん壊していました。
あのとき、7人を通って、文の長さは18字から9字に半減していました。

先に一行だけ置きます。AI駆動開発とは、AIを補助ではなく実装の主役に置いて開発を進める方法のことです。

題材は、開発サイクルを自動で回す仕組みです。工程ごとにAIの役割を分け、成果物を次の工程へ渡していきます。この土台のことを、ここではハーネスと呼びます。

前置きはさておき、本題に入ります。

今日は、このハーネスを自社で作るか、提供元のネイティブ機能に乗るかを、7つの軸で比べた話をしていこうと思います。

① 教科書どおりに、自社でオーケストレーションを組む

AI駆動開発（AI-Driven Development）とは

AI駆動開発とは、ソフトウェア開発の工程そのものをAI前提で組み直し、設計・実装・テスト・運用をAIに回させる開発のやり方です。略してAIDDとも呼ばれます。

「AIにコードを書かせること」ではありません。書かせたものを動かし、結果を読み、次の指示に反映する——このフィードバックの輪を自動で回すことが中心にあります。人が毎回介在して次を指示しているうちは、まだ次に述べるAIアシスト開発の段階です。

従来開発・AIアシスト開発・AI駆動開発の違い

	人がやること	AIがやること
従来開発	設計も実装もテストも人	補完・検索の支援
AIアシスト開発（AIAD）	判断と指示を毎回出す	頼まれた単位のコードや文章を書く
AI駆動開発（AIDD）	仕様と受け入れ条件を決める	実装・テスト・修正を条件を満たすまで繰り返す

境目は「誰がループを回しているか」です。人が1手ずつ指示しているならアシスト、終了条件を渡して回っているなら駆動です。

AI駆動開発が注目される背景

• 開発人材の不足 — 採用で埋める手が現実的でなくなった
• 開発スピードへの要求 — 作って出すまでの期間が短くなった
• レガシーシステムの負債 — 読み解きと移行に人手がかかりすぎる
• ツールの実用化 — Copilot、ChatGPT、Cursorなどが業務で使える水準になった

4つ目が転換点でした。「試してみる」対象だったものが、使わない場合の説明が要る側に回ったのが、この2年の変化です。

AI駆動開発の3つのレベル

	範囲	成立する条件
レベル1 AIアシスト開発	個人の作業。補完と生成	ツールを配れば始まる
レベル2 AI駆動チーム開発	チームの工程。レビューやテストも含む	共通のルールと成果物の型が要る
レベル3 AIネイティブ開発	開発プロセス全体をAI前提で再設計	仕様が機械可読な形で残っていること

飛び級はできません。レベル2の「成果物の型」が揃っていない組織がレベル3を狙うと、AIが読む前提の仕様が存在しないため、指示が毎回口伝になります。

AI駆動開発のアプローチ3類型

• アシスタント型 — 人が主で、AIが補助する。導入の敷居が最も低い
• 自律型 — AIが計画から実行まで担い、人は結果を見る
• ハイブリッド型 — 工程ごとにどちらが主かを変える

実務で選ばれるのはハイブリッド型です。全自律にすると、確認の仕組みを先に作らないかぎり品質が読めません。どの工程を自律にするかを、工程ごとに決めるのが現実解です。

仕様駆動開発｜コードではなく仕様を起点にする

AI駆動開発の中核にあるのが、先に仕様を書き、そこからAIに実装させるやり方です。AWSはこれをAI-DLC（AI-Driven Development Lifecycle）として整理し、Kiroのように仕様を第一級の成果物として扱うツールも出ています。

ただし、仕様書を完璧に書き切ろうとすると失敗します。仕様は正解ではなく目次（インデックス）として使うのが実務的です。詳細まで書いた実装計画は、実装が進むと必ずずれます。

AI駆動開発が向く領域・向かない領域

	例	理由
向く	定型的なCRUD、テストコード、移行、ドキュメント整備	正解の形が事前に決まっており、機械で判定できる
向かない	前例のないUIの設計、業務上の判断が絡む仕様の決定	何が正解かを、外から与えられない

分かれ目は難易度ではなく「合否を機械で判定できるか」です。難しくても判定できる仕事は回り、簡単でも判定できない仕事は回りません。

メリット1｜開発期間が短くなる

実装とテストコードの作成が並行して進むため、同じ機能を出すまでの日数が短くなります。

短くなるのは実装の時間であって、決める時間ではありません。仕様が決まっていない期間は、AIを入れても縮みません。

メリット2｜人的リソースを配置し直せる

定型的な実装がAI側に寄るぶん、人は仕様の決定、レビュー、業務側との調整に回れます。

メリット3｜コード品質が揃い、バグが早く見つかる

書き方の癖が減り、レビューの指摘が減ります。テストコードを同時に書かせると、実装より先に不備が出ます。

メリット4｜ドキュメントが整備される

仕様書、API定義、変更履歴の生成が実装と同時に回せます。「あとで書く」が構造的になくなるのが、この項目の本当の効用です。

メリット5｜レガシー化を抑え、保守コストを下げる

既存コードの読み解き、依存関係の洗い出し、移行の下書きをAIに任せられます。

移行そのものより、「いま何が動いているか」を可視化する工程で効きます。仕様書が失われた古いシステムほど、効果が大きくなります。

デメリット1｜ハルシネーション（もっともらしい誤り）

存在しない関数やAPIを、実在するかのように書いてくることがあります。

対策は「読んで気づく」ではなく「機械で落とす」です。型チェック、ビルド、テスト、静的解析。人のレビューを最後の砦にすると、量が増えたぶんだけ通り抜けます。

デメリット2｜セキュリティとソースコードの流出

社内コードを外部サービスへ送ることになるため、何を送ってよいかを先に決める必要があります。

• 学習に使われない契約形態か
• 送ってはいけない情報（鍵・個人情報・顧客名）をどう止めるか
• 生成されたコードのライセンスをどう確認するか
• 生成コードの脆弱性を、どの工程で検査するか

3つ目と4つ目が抜けがちです。入口（何を送るか）だけ整えて、出口（何が入ってきたか）を見ていない構成をよく見ます。

デメリット3｜依存とスキルの空洞化

生成されたコードを読まずに通す運用が続くと、障害が起きたときに直せる人が社内に残りません。

「書けること」ではなく「読んで判断できること」を維持するのが要点です。レビューを形式にしないでください。

自然言語の指示だけでは、制約は守り切れない

「この規約に従って」とプロンプトに書いても、守られる保証はありません。長い会話のなかで、指示は薄まります。

守らせたい制約は、文章ではなく仕組みの側に置きます。CIのチェック、リンタ、テスト、フック。これはテストファーストと同じ発想です。

工程別1｜要件定義・設計

要求の分解、ユーザーストーリーの生成、検討観点の洗い出しに使えます。

「観点を出させる」使い方がいちばん外れません。結論を出させるのではなく、人が見落としている論点を列挙させると精度が安定します。

工程別2｜実装

コード生成、リファクタリング、テストコードの作成。いちばん効果が見えやすい工程です。

実装させる単位を小さく切るほど、手戻りが減ります。1ファイル1責務まで割ってから渡してください。

工程別3｜テスト・品質保証

テストケースの洗い出し、境界値の列挙、テストデータの生成。

実装したAIと、テストを書くAIを分けると、見落としが減ります。同じ文脈で書かせると、同じ思い込みでテストも書きます。

工程別4｜運用とドキュメント

ログ解析、アラートの整理、手順書の生成、変更履歴の整備。

運用は「毎回同じ形式で出る」ことが価値になる工程です。文章のうまさより、書式が固定されているかを優先してください。

主なツールの地図と選び方

層	例	選ぶときに見るところ
基盤のLLM	ChatGPT / Claude / Gemini	データの扱い、コンテキストの長さ、費用
コード生成・IDE連携	GitHub Copilot / Cursor / Claude Code / Amazon Q	既存のリポジトリと開発環境に入るか
仕様駆動	Kiro など	仕様を成果物として管理できるか
テスト・品質	静的解析、テスト生成	CIに組み込めるか
運用（AIOps）	ログ解析、アラート最適化	既存の監視と繋がるか

選定でいちばん効くのは「CIに組み込めるか」です。人が手で呼ぶ道具は、忙しくなると使われなくなります。

導入の7ステップ

• 1. 目的の整理 — 速度か、品質か、人手か。1つに絞る
• 2. 環境整備 — 使ってよいツールと、送ってよい情報を決める
• 3. データ整備 — 既存コードとドキュメントを、AIが読める場所に置く
• 4. 試行 — 1チーム・1リポジトリで試す
• 5. 評価 — 決めた指標で測る
• 6. 改善 — 詰まった工程だけ作り直す
• 7. 本格導入 — 型が固まってから広げる

3番目を飛ばす組織が多いのですが、ここが効きます。仕様も設計も人の頭の中にしかない状態では、AIに渡す材料がありません。

組織に定着させるロードマップ

段階	やること	終わったといえる状態
スモールスタート	1チームで試す	効果と限界が数字で言える
ガバナンス整備	利用ルール・レビュー基準・検査の自動化	ルールが仕組みとして実行されている
全社展開	教育と横展開	新しいチームが自力で始められる

2段目を飛ばして全社展開すると、あとから止める側の仕事だけが増えます。

効果をどう測るか（KPIの置き方）

• 着手から本番までの日数（リードタイム）
• 本番に出た不具合の件数
• レビューで差し戻された回数
• 生成されたコードのうち、そのまま採用された割合

「生成した行数」をKPIにしないでください。増やすほど良い数字は、増やす動機だけを作ります。

つまずきやすい3点

• ツールの導入が目的になる — 配っただけで、工程が前のままになっている
• セキュリティとガバナンスが後回し — 走り出してから止める話になる
• 開発プロセスをAI前提に組み直していない — 人が1手ずつ指示する前提のまま、道具だけが変わっている

3つ目が本丸です。工程を変えずに道具だけ替えると、レベル1で頭打ちになります。

導入しやすい3つのパターン

• レガシー刷新 — 既存コードの読み解きと移行。効果が数字で出やすい
• 新規サービス開発 — しがらみが無く、最初からAI前提で組める
• 業務アプリの内製化 — 小さく、失敗しても影響が閉じている

最初の1件は3番目から始めるのが安全です。止まっても業務が止まらない範囲で、型を作れます。

最初は、私が組みました。工程を定義し、渡すものを決め、順番を制御する。

理由は単純です。業務に合わせて制御したかったからです。

→ 工程ごとに役割を分ける
→ 前の工程の成果を次へ渡す
→ 指摘を台帳で管理する
→ 進捗と停滞を監視する

動きました。 そして、動いただけでなく、提供元のループより良い部分がありました。

ここまでは、教科書どおりです。
規模を置いておきます。工程は4つ、役割は2つ、1サイクルの成果物は3種類。 半年で回した回数は数十回です。

ここまでが、AI駆動開発の教科書どおりの整理です。レベルを見極め、仕様を起点にし、機械で判定できる仕事から渡し、ガバナンスを仕組みで持つ。この型どおりに組めば、開発は回ります。

この記事の後半で扱うのは、その型を実際に組んだあとの話です。自社でオーケストレーションを作るか、ツール側が持っている機能に載せるか。同じ仕事を両方で回して、7つの軸で比べたときに何が分かれたのかを見ていきます。

要素	数
工程	4つ
役割	2つ
1サイクルの成果物	3種類

② そのとおりに運用して、7軸に分かれる

半年ほど回して、比較の軸が7つに整理されました。そして、4軸と3軸で勝ち負けが分かれました。

自作が勝った4軸はこうです。

① 原文保全の強制。 これが最大の発明でした。指摘や指示をタグで囲み、一文字も省略せずに転記させる。 そして転記されたかを機械で検査します。

② 台帳。 指摘に永続的な識別子を振り、履歴を持ち、停滞を検知します。台帳をコードが更新するので、モデルが規約を守ることに依存しません。

③ 記憶の階層化。 実装する側のツール操作のノイズが、レビューする側の文脈を汚染しません。

④ 型付きの契約と監査可能性。 何が渡されたかが記録に残ります。

そして、負けた3軸がこれです。

① スキーマの外に落ちたデータは、永久に消える。
② 非構造なコンテキストの扱いが素朴。
③ 進化コストが一桁重い。
勝ち負けの内訳は4対3です。平均すると意味を失うので、軸ごとに見ます。

勝ち負けの内訳は4件対3件でした。勝った4件はいずれも、提供元のループに存在しない仕組みです。
ところで、勝った4件のうち最初の1件について、記録には「これが最大の発明」と書かれています。ただ、発明と呼べるほどのことはしていません。「一文字も省略せず転記せよ」と書いて、転記されたかを機械で数えているだけです。とはいえ、その1件が品質のほぼ全部を決めていました。

③ そして、いちばん深い負けは①だと分かる

3つのうち、①が構造的でした。

自作の受け渡しは、決められた項目しか運べません。 設計時に「これを渡す」と決めたものだけが次へ行きます。

対して、会話をそのまま引き継ぐ方式は違います。全部の記録が生きているので、「そういえばさっき言っていたあれ」と遡って回収できます。

言い換えると、こうなります。

→ 項目で引き継ぐ — 損失あり・確実
→ 会話で引き継ぐ — ほぼ無損失・不確実

確実に一定量が失われるのと、たいてい失われないが保証がないのと、どちらを選ぶかという話でした。

②も具体的です。渡せる非構造テキストの上限が、8,000文字（約2,000トークン）、上流からの持ち込みが6,000文字、出力の控えが1,500文字。しかも切り詰めは文の途中でも容赦なく切ります。

20万トークンを扱える時代に、予算が一桁小さい設計でした。

③は運用で効きます。引き継ぐ項目を1つ増やすだけで、スキーマの変更、指示文の変更、完了処理の変更、移行作業が全部必要になります。設定ファイルに1行足すのとは違います。

証拠も残っています。 目標の抽出処理に、4段のフォールバックが生えていました。タグで取れなければ見出しから、それも駄目ならJSON、最後は正規表現。この方式が実際に何度も壊れた記録です。
負けの3軸を、数字で並べ直すとこうです。

軸	自作の値	意味
非構造テキストの上限	8,000字	約2,000トークン
上流からの持ち込み	6,000字	文の途中で切れる
出力の控え	1,500字	同上
引き継ぎ項目を1つ増やす手数	4箇所	スキーマ・指示文・完了処理・移行

④ 原因は「全部を自作の対象にしていた」こと

原因を一つに絞ると、これでした。

守るべきものと、差し替えるべきものを分けていませんでした。

原文保全と台帳は、守るべきものです。ここは提供元のループには無く、しかも品質に直結します。

一方、コンテキストの持ち回りや引き継ぎ項目の設計は、まだ探索中のものでした。探索中のものを自作の枠に固めると、変えるたびに一桁重いコストがかかります。

固めてよいのは、答えが出たものだけでした。

⑤ 直してみる — 仕事の種類で、載せる先を変える

結論は、優劣ではありませんでした。

→ 既知のワークフローを、高い信頼性で回す層 → 自作が優位
→ 引き継ぎ設計をまだ探索している段階の仕事 → ネイティブのループが勝つ

そして、時間軸の話もあります。

自作していた仕組みと同等のものが、後から提供元の標準機能として登場しました。 決定論的なスクリプトで処理を並列化し、構造化された出力を強制する仕組みです。

私の設計が、提供元の進化によって追認された格好です。

ただし、同時にこうも記録しています。半年前に作ったシステムだが、まだ部分的には提供元のループの精度を上回っている。

追いつかれるが、まだ抜かれてはいない。 その状態で、どこを守りどこを差し替えるかを決めることになりました。
線引きの結果は、守るものが2つ、差し替えるものが3つでした。守るのは原文保全と台帳、差し替えるのはコンテキストの持ち回り・引き継ぎ項目・並列の制御です。
差し替えに動かした工数は、2週間でした。守る側には手を入れていません。

差し替えに動かした工数は10日でした。守る側には1行も手を入れていません。
記録にはこう残しています。「既知のワークフローを高信頼で回す層では自作が優位」「引き継ぎ設計をまだ探索している段階の仕事ではネイティブが勝つ」。実は、この2件は同じプロジェクトの中に同居します。ただし、どちらに載せるかは工程ごとに決められます。工程は4件、自作へ載せたのは2件でした。

⑥ あとで知った — 伝言ゲームには、定理があった

素朴な観察のつもりでしたが、多段で情報が減ることには、情報理論の定理がありました。

データ処理不等式（Data Processing Inequality）です。

内容はこうです。3つの確率変数がマルコフ連鎖をなすとき、途中の変数をどう処理しても、元の変数についてその中に含まれる情報を増やすことはできない。

もっと短い言い方も添えられています。「後処理は情報を増やせない。」

多段のAIパイプラインは、まさにこの連鎖です。

→ 指摘が出る（元の情報）
→ 次の工程が要約して受け取る（処理）
→ その次がさらに要約する（処理）

どれだけ賢いモデルを後段に置いても、前段で落ちた情報は戻りません。 賢さは処理の質を上げますが、不等式の向きは変えられない。

小学校の伝言ゲームで、整理した人がいちばん壊していた理由もこれでした。整理は処理です。処理は情報を増やしません。

だから、原文保全が最大の発明だったのだと思います。あれは工夫ではなく、唯一の逃げ道でした。減らさずに渡すこと以外に、情報を保つ方法がない。
実際、要約を挟んだ工程と挟まない工程で、指摘の取りこぼしが8件と0件に分かれました。同じ入力、同じモデルです。

新しい理屈は、ひとつも要りませんでした。

記録に残っている実例

自作側が何で勝っているかは、決定記録を見ると具体的です。

2026年2月2日の決定。 各役の出力を別々に保存し、状態と時刻を持たせています。再試行のときは、完了済みの出力をそのまま残す。 目的は3件と書かれています。失敗した場所を特定すること、利用者が各段を確認できること、そして完了した段を飛ばして再開できることです。

2026年2月3日の決定。 使うモデルの解決順は5段あります。

“`
実行時の指定 > 役 > 既定の役 > 既定の提供元 > 環境変数
“`

そして、APIキーはデータベースに置かず、環境変数の名前だけを持ちます。 鍵そのものではなく、鍵の在り処を持つ。差し替えるときに触る場所が1件で済みます。

この2件が、原文保全と台帳という表現の中身です。どちらも、あとから追えるようにするための構造であって、性能のための構造ではありません。

⑦ 何が変わったか

議論の立て方が変わりました。

“`
前：自作とネイティブ、どちらが優れているか
後：この仕事は、既知か探索中か
“`

優劣を決めようとしていたのが間違いでした。 7軸のうち4勝3敗という結果は、平均すると意味を失います。

⑧ 現場で使うなら、この2枚

表1：どちらに載せるか

仕事の性質	自作ハーネス	ネイティブのループ
手順が確定している	こちら	—
監査記録が要る	こちら	—
指摘を取りこぼせない	こちら（原文保全）	—
引き継ぐ項目がまだ決まらない	—	こちら
予期しない情報を拾いたい	—	こちら
試行の回転を上げたい	—	こちら

表2：多段パイプラインで情報を減らさない3点

点	やること	外すとどうなるか
1	原文をタグで囲んで渡す	各段で要約され、細部が溶ける
2	省略禁止を明示し、機械で検査	指示だけでは守られない
3	識別子を永続化して台帳で追う	どれが未対応か分からなくなる

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「優劣ではなく、仕事の種類で決める」。 どちらが優れているかを議論している限り、決まりません。決めるのは仕事の性質のほうです。

2件目、「スキーマの外に落ちた情報は、永久に消える」。 定義した枠に入らなかったものは、記録されません。あとから欲しくなっても取り戻せません。

3件目、「既知の工程は自作、探索中の工程はネイティブ」。 手順が確定している仕事は自作が勝ちます。引き継ぎ方をまだ探している仕事は、汎用のループが勝ちます。

4件目、「守るものと差し替えるものを、先に分ける」。 分けずに全部を自作すると、外側が良くなるたびに追随の労力が発生します。

5件目、「全部を自作すると、進化コストを自分で背負う」。 7軸で比べたとき、勝ち負けが入れ替わったのはここでした。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

提供元は、これからも機能を足してきます。自作した部分は、順に追いつかれます。

→ 自作する → 一時的に勝つ
→ 提供元が同等機能を出す → 差が消える
→ 消える → 維持コストだけが残る
半年で追いつかれた機能は2つ、まだ追いつかれていない機能は2つでした。追いつかれた側の維持に使った時間は、振り返ると無駄です。

だから、追いつかれない部分だけを自作してください。

追いつかれにくいのは、自社の業務に固有な制約です。原文保全は普遍的な工夫なので、いずれ標準になります。一方、自社の工程・自社の台帳・自社の監査要件は、提供元が作る理由がありません。

そして最後に、正直に書いておきます。この7軸の比較は、私が自分の設計を評価したものです。 作った本人が採点しているので、4勝3敗という数字自体は割り引いて読んでください。

負けの3軸を構造的だと認めたのは、割り引いたあとに残ったものです。

半年で追いつかれた機能は2件、まだ追いつかれていない機能は2件です。追いつかれた側の維持に使った時間は、振り返ると無駄でした。

もう1件、記録から引いておきます。「6か月前のシステムだが、まだ部分的に精度で上回っている」。ところが、この状態は長く続きません。とはいえ、追いつかれるまでの6か月で回した数十回のサイクルは、そのまま資産になりました。

もう1件、判断の言葉を残しておきます。「スキーマ引き継ぎは損失あり・確実」「会話引き継ぎはほぼ無損失・不確実」。ただし、どちらを選ぶかは好みではなく、仕事の性質で決まります。

最後に、社内の判断を1件だけ引いておきます。新しく参画した人から、開発フローや命名規則やシークレット管理の規定を問われたときの回答です。「これも、すでに構成が異なるので、一貫したルールは適応できない気がします。適当にやってください」。

ところで、これは投げやりな返事に見えて、標準化しないという判断です。前段にはこう書かれています。「それをソロ開発に適用するには不適切な気がするので、ローカルルールを決めて運用すれば良いと思います」。

全社で1つの型に寄せるより、プロジェクトごとに決めさせるほうが速い。 自作とネイティブの線引きも、同じ考え方の上にあります。ただし、この判断には代償があります。新しく入った人が、毎回ゼロから聞くことになります。

関連して、プロンプトエンジニアリングを属人化させない話と、アジャイル開発をAIで並行させたときの衝突話を別に書いています。ベンダーロックインで乗り換えられなくなる話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、AIプロダクト開発のページに整理しています。

---

自作といえば、本棚を作ったことがあります。既製品より高くついて、しかも傾いています。

それでも捨てられないので、いまも斜めの棚に本を置いています。 何を自作するかは、先に決めておくべきでした。

以上です。

AI駆動開発のよくある質問

AI駆動開発とAIアシスト開発は何が違いますか？

境目は「誰がループを回しているか」です。人が1手ずつ指示を出し、頼んだ単位でAIがコードを書くのがAIアシスト開発（AIAD）。人は仕様と受け入れ条件を決めるだけで、AIが実装・テスト・修正を条件を満たすまで繰り返すのがAI駆動開発（AIDD）です。AI駆動開発の本質はコード生成ではなく、フィードバックの輪を自動で回すことにあります。

AI駆動開発の3つのレベルとは何ですか？

レベル1がAIアシスト開発で、個人の補完と生成。ツールを配れば始まります。レベル2がAI駆動チーム開発で、レビューやテストも含むチームの工程。共通のルールと成果物の型が要ります。レベル3がAIネイティブ開発で、開発プロセス全体をAI前提に再設計した状態。仕様が機械可読な形で残っていることが条件です。飛び級はできません。

AI駆動開発のメリットとデメリットを教えてください。

メリットは開発期間の短縮、人的リソースの再配置、コード品質の均一化とバグの早期発見、ドキュメント整備の促進、レガシー化の抑制と保守コスト削減の5つです。デメリットはハルシネーション（もっともらしい誤り）、セキュリティとソースコード流出、AIへの依存とスキルの空洞化の3つ。短くなるのは実装の時間であって、決める時間ではありません。

AI駆動開発はどんな仕事に向いていますか？

分かれ目は難易度ではなく「合否を機械で判定できるか」です。定型的なCRUD、テストコード、移行、ドキュメント整備のように正解の形が事前に決まっている仕事は回ります。前例のないUIの設計や、業務上の判断が絡む仕様の決定のように、何が正解かを外から与えられない仕事は回りません。難しくても判定できる仕事は回り、簡単でも判定できない仕事は回りません。

AI駆動開発はどう導入すればよいですか？

7ステップです。目的を1つに絞る、使ってよいツールと送ってよい情報を決める、既存コードとドキュメントをAIが読める場所に置く、1チーム1リポジトリで試す、決めた指標で測る、詰まった工程だけ作り直す、型が固まってから広げる。3番目のデータ整備を飛ばす組織が多いのですが、仕様が人の頭の中にしかない状態ではAIに渡す材料がありません。

AI駆動開発とは何ですか？

ソフトウェア開発の工程そのものをAI前提で組み直し、設計・実装・テスト・運用をAIに回させる開発のやり方です。AIDDとも呼ばれます。人が仕様と判断を持ち、コードを書く作業はAIが担います。複数のAIを工程ごとに役割分担させ、自動で回す構成まで含めて指すことが多くなっています。

AI開発の基盤は、自社で作るべきですか？

仕事の種類によります。既知の工程を高い信頼性で繰り返す用途では自作が優位です。原文をそのまま次の工程へ渡す強制、指摘の台帳、監査記録といった仕組みを自分で持てるからです。一方、引き継ぎの設計自体をまだ探している段階では、提供元のループのほうが勝ちます。

自作の基盤が構造的に負けるのは、どこですか？

設計時に予期しなかった情報が永久に消える点です。自作の受け渡しは決められた項目しか運べません。会話をそのまま引き継ぐ方式なら「そういえばさっき」と遡って回収できますが、項目で引き継ぐ方式では最初から存在しなかったことになります。損失は確実に起きるが、量は読める、という性質です。

多段のAIパイプラインで、品質が落ちる原因は何ですか？

各工程での要約です。ある工程が受け取った内容を要約して次へ渡すと、その時点で情報が減ります。減った情報は後段でどれだけ処理しても戻りません。対策は要約させないことで、原文をタグで囲み、一文字も省略せずに転記させ、転記されたかを機械で検査します。

自作の基盤は、どのくらいで陳腐化しますか？

提供元の進化に追われます。実際に、自作したものと同等の機能が後から提供元の標準機能として登場しました。ただし半年前に作ったものが、部分的にはまだ精度で上回っている状態でもあります。追いつかれる前提で、どこを守り、どこを差し替えるかを決めておく必要があります。