わたしたちギグワークスクロスアイティは自社製品の開発にAIを取り入れ、モック作成から設計、製造（実装）、テストまでを自動化しています。実際に自動化を進めると、コードを速く生成できても、開発全体が同じように速くなるわけではないと分かります。仕様の未確定、判断待ち、レビューの滞留、モックに残る不要なコードが、新たなボトルネックになるためです。AIの速度を生かすには、開発手法とリーダーの役割を見直さなければなりません。

【関連記事】AI開発がうまくいかない理由とは？Superpowersは何を変えるのか

AIの速度に開発体制が追いつかない

AIを開発に組み込むと、人がコードを書いていた頃には目立たなかった待ち時間が表面化します。AIはモックを作り終えると、すぐに設計や製造へ進みます。しかし、次の作業に必要な仕様や判断材料がそろっていなければ、そこで停止します。AIの性能を引き上げるだけでは、この待ち時間を短縮できません。

実装の加速で発生する待ち時間

私たちギグワークスクロスアイティは、デコールシリーズやごきげんクラウドシリーズなどの自社製品を開発しています。現在は自社製品の開発工程にAIを導入し、モック作成、設計、製造、テストの全工程を自動化しています。担当者がAIからコードの提案を受けるだけでなく、AIが成果物を作成し、実行結果を確認しながら次の工程へ進みます。

コードを作る時間が短くなると、開発のボトルネックも変わります。Google CloudのOffice of the CTOによる実務報告では、人とAIエージェントが共同で開発した結果、ボトルネックがコード作成からレビューと統合へ移ったと説明されています。AIが短時間で大量の変更を加える一方、担当者が内容を理解し、設計との整合性や影響範囲を確認するには相応の時間がかかります。

従来の開発では、担当者が実装している間に、リーダーが次の仕様を確認したり、関係者と調整したりする余裕がありました。実装に数日かかれば、その間に判断材料をそろえられます。AIが同じ作業を短時間で終えると、準備が間に合いません。実装時間が短くなるほど、判断や準備にかかる時間が開発全体を左右するようになります。

AIの導入で表面化する「ブロッカー」

AIの作業を止める原因は、難しい技術課題だけではありません。要件の一部が決まっていない、業務ルールに例外がある、データモデルと画面項目が対応していない、APIの入出力が決まっていないといった問題でもAIは停止します。開発環境に接続できない、必要な権限がない、認証情報やテストデータが用意されていない場合も同じです。

完了条件が曖昧なタスクもAIを止めます。「予約機能を作る」とだけ指示しても、予約可能な時間、重複した予約の扱い、取消期限、権限ごとに許可する操作が決まっていなければ、AIは自分で前提を補うか、担当者に質問します。前者では誤った実装が生まれ、後者では回答を得るまで作業が止まります。どちらにしても、準備不足は手戻りや待ち時間を招きます。

DORAは、AIが組織の強みと弱みを増幅すると報告しています。要件を整理し、小さな単位で開発し、自動テストを整備しているチームは、AIの速度を成果に結びつけやすくなります。反対に、仕様が曖昧なまま担当者の判断で補ってきたチームでは、未解決の問題が短時間に積み上がります。AIは開発工程に残る問題を解消するのではなく、早い段階で表面化させます。

AIに渡す仕事を先回りして準備する

設計や製造を妨げる問題は、AIに仕事を渡す前に取り除かなければなりません。要件、業務ルール、データ、API、権限、環境、完了条件を確認し、AIがすぐに着手できるようにします。判断が必要になる場面を予測し、誰がいつ決めるのかも明確にします。AIに指示した後で不足に気づいていては、生成速度を生かせません。

タスクの一覧も、優先順位を付けるだけでは不十分です。仕様が未確定のタスクや、外部システムへの依存が残るタスクは、問題を解消してからAIに渡します。すぐに実行できるタスクを複数用意しておけば、判断待ちが発生しても、AIを別の作業へ移せます。リーダーは進捗だけでなく、次にAIに渡せるタスクがどれだけあるかを管理します。

リーダーがやるべきことを見直す

従来のリーダーは、自分の担当作業を持ちながら、必要に応じて設計や実装を手伝い、難しい部分を引き取る余裕がありました。しかし、複数のAIが同時に動くと、質問、承認、レビュー、優先順位の判断が短時間に集中します。リーダーが一つの実装作業にかかりきりになっている間に、ほかのAIが回答待ちになれば、チーム全体が止まります。

AIが開発の中心を担う体制では、リーダーはワークロード管理に専念します。各タスクの優先順位と依存関係を把握し、AIが現在の作業を終える前に、次のタスクに必要な仕様、判断材料、テストデータ、実行環境を準備します。レビューも完成後にまとめて行わず、変更を小さく分けて、一度に確認できる量に抑えます。

技術力が不要になるわけではありません。AIが作ったコードや設計の問題を見抜くには、システム全体を理解できる技術者が必要です。ただし、リーダーの成否は、自分で書いたコードの量では決まりません。AIが現在の作業を終える前に課題を見つけ、次の仕事を用意し、チーム全体を止めない能力が開発速度を左右します。

開発を妨害する「ジャンクコード」

AIは、画面や操作を確認するためのモックを短時間で作れます。早い段階で完成イメージを共有できるため、要求の漏れや認識の違いも見つけやすくなります。ただし、画面が要求どおりに動いていても、そのソースコードを正式な開発にそのまま使えるとは限りません。

モックに残る不要コード

AIで自社製品のモックを作成すると、画面上では要求した動作を確認できました。しかし、リーダーがソースコードを調べると、モック段階でしか使わないジャンクコードが含まれていました。リーダーは問題を指摘し、AIに修正させてから次の工程へ進めました。

ジャンクコードは、正式な実装には不要な仮の処理や、後から保守しにくいコードを指します。モックでは、完成形を早く確認するために、正式な実装では採用しない処理を使う場合があります。一般的には、値をソースコードに直接書く、仮のデータ構造を使う、同じ処理を複数の場所に置く、認証や例外処理を省くといった方法です。モックとして使うだけなら問題にならなくても、本番用のコードに引き継げば保守が難しくなり、障害の原因にもなります。

Microsoftの技術資料でも、試作用のコードを別の用途に転用すると、技術的負債になり得ると説明しています。動いているコードを捨てるのは惜しく見えますが、短時間で動かすために追加した仮の処理は、本番運用に必要な品質、保守性、安全性を考慮して設計されていない場合があります。不要な仮実装を取り除いて初めて、正式な設計へ進めます。

仮実装が正式な仕様として扱われる

人が設計書を書く場合は、モックの目的と正式な仕様を区別しながら内容を整理できます。ソースコードを基にAIに設計書を作らせる場合、AIがコードに書かれた処理を設計上の意図と仮実装に正しく分けられるとは限りません。ソースコードに残った処理を正式な仕様とみなし、設計書に記載する場合があります。

仮実装が設計書に入り込むと、単なるコード上の問題では済みません。画面上の都合で作った項目が正式なデータモデルに追加されたり、一時的な処理順序が業務ワークフローとして記録されたりします。AIがその設計書を基に製造を進めれば、誤った前提に合わせて新しいコードを作ります。さらに同じ前提でテストを作ると、本来は修正すべき動作が、テスト上は正しい動作として扱われます。

設計書、コード、テストの内容が一致していても、システムが正しいとは限りません。最初に与えた前提が誤っていれば、後の成果物もその誤りを引き継ぎます。同じAIに設計、製造、テストを続けて任せる場合は、特に注意が必要です。AIが先に作った設計やコードと矛盾しないテストを作っても、業務要件に合っているという保証にはなりません。

AIが作った成果物は、後工程へ渡す前に工程ごとに確認します。ソースコードを整理してから設計書を作り、設計を確認してから製造へ進み、テストでは設計書だけでなく元の業務要件も参照します。Google Cloudが紹介するDORAの調査でも、AIによる開発では、バージョン管理、自動テスト、人によるレビューを組み合わせ、小さな単位で変更する方法が重視されています。速く進めるためにも、誤りが後工程へ広がる前に、人が確認する工程を設ける必要があります。

成果物を異なる観点から確認する

ソースコードだけを詳しく読んでも、業務上の誤りをすべて見つけられるわけではありません。実装としては正しくても、データの持ち方、利用者の操作手順、権限設定、外部システムとの連携方法に誤りが残っている場合があります。AIが作った成果物は、データモデル、業務ワークフロー、UI、API、業務要件など、複数の観点から確認します。

データモデルでは、項目の型や関連だけでなく、誰がどの時点で更新するのかを確かめます。業務ワークフローでは、正常に完了する流れに加えて、差し戻し、取消、再実行、期限超過が起きた場合の流れも確認します。UIでは、利用者が迷わず操作できるか、誤操作を誘発しないかを見ます。APIでは入出力、認証、エラー、再送時の動作を確認し、最後に、実際の処理手順や権限が業務要件と矛盾していないかを確かめます。

これらを完成後の総合レビューだけで確認しようとしても、間に合いません。AIが大量のコードを作った後では、変更の意図と影響範囲を追うだけでも時間がかかります。モック、設計、製造、テストの各工程で観点を変えて確認すれば、問題が小さいうちに修正できます。リーダーの技術力は、すべてを自分で実装するためではなく、AIが見落とした問題を見抜き、適切な担当者やAIに修正を指示するために使います。

確認を担当する人やAIは、成果物を作ったときとは異なる観点から内容を確認します。コード、業務フロー、データ更新、権限など、レビューごとに確認対象を分ければ、同じ前提のまま検証を重ねて問題を見落とす危険を減らせます。

AI開発を止めずに動かすために

AIエージェントは、長時間動かせば自動的に大きなシステムを完成させるわけではありません。情報が不足すれば質問し、権限がなければ接続に失敗し、作業が大きすぎれば、それまでの作業内容を十分に参照できなくなります。生産性を高めるには、停止を一律に減らすのではなく、平時に避けるべき停止と、有事に必要な停止を分けなければなりません。

同じ「停止」を繰り返さない

AIエージェントが頻繁に止まると、そのたびに担当者が進捗やログを確認し、原因を調べ、再開の指示を出します。1回の対応が短くても、複数のAIが同時に動けば割り込みが続きます。担当者は自分の作業に集中できず、AIも回答を待つため、期待したほど生産性は上がりません。

停止した場合は、その場で再開させるだけでなく、理由を記録します。情報不足、指示の曖昧さ、権限不足、外部サービスへの接続失敗、一度に参照できる情報量の上限超過、テスト失敗、承認待ち、タスクの過大化などに分け、どの工程で起きたのか、再開までに何が必要だったのかを確認します。同じ理由で停止を繰り返すなら、個別の失敗ではなく、エージェント設計や開発環境の問題です。

Anthropicが長時間稼働する開発エージェントを検証した際には、大規模な開発作業を一度に任せると、AIが参照できる情報量の上限に達し、実装を完了できない問題が起きました。その後、初回に環境を整えるエージェントと、実装を少しずつ進めるエージェントに役割を分け、進捗や残作業を次のセッションへ引き継ぐ方法を採用しています。別の検証では、計画、生成、評価を別々のエージェントに担当させました。

長時間動かすには、長い指示文を与えるより、タスクを1回で完了できる大きさに分ける方が有効です。変更した内容、テスト結果、未解決の問題、次に行う作業も記録します。通常のテストで失敗した場合は、AIがログを読み、修正し、再実行できるようにします。接続先や権限も着手前に用意します。停止原因を一つずつ取り除けば、担当者が介入する回数を減らせます。

平時は止めず、有事には必ず止める

通常の開発で起きるエラーは、可能な限りAI自身で処理させます。テストが失敗した、必要なファイルが見つからない、依存関係のバージョンが合わないといった問題に対して、毎回リーダーの判断を求めていては作業が進みません。確認方法、再試行の回数、代替手順をあらかじめ決め、許可された範囲で復旧できるようにします。

ただし、平時に止めないからといって、AIに自由な操作を許すわけではありません。本番環境に未承認の変更を加えようとした場合や、データの削除、機密情報・認証情報の外部送信、権限の拡大、未承認の外部サービスや依存関係の追加を検知した場合は、直ちに停止させます。作業範囲を超える大規模な変更、システムの根幹に関わるデータモデルの矛盾、同じ処理を繰り返すループも停止対象です。

OWASPは、AIエージェントの主なリスクとして、過剰な自律性、ツールの悪用、権限昇格、情報流出、復旧困難な操作、複数のエージェントに広がる連鎖的な障害などを挙げています。対策として、利用できるツールと権限を必要最小限に抑え、読み取りと書き込みを分け、重要な操作には人の承認を求めています。

平時と有事の区別を、AIへの指示文に「危険な操作をしない」と書くだけで済ませてはいけません。開発用と本番用の権限を分け、保護されたブランチに直接変更できないようにします。重要な処理は承認を得るまで実行できない仕組みにし、操作履歴を残します。再試行の回数が想定を超えた場合や、許可した範囲を超える変更を検知した場合は、AIとは別の仕組みから強制停止できるようにします。平時には作業を続けられ、有事には確実に止まる仕組みを実行環境に組み込みます。

短い単位でAIに次の仕事を渡す

AIが開発の中心になると、要件定義、設計、製造、テストという工程を大きく区切り、一つずつ完了させて引き渡す進め方では対応しにくくなります。AIは短時間で成果物を作るため、工程の区切りが大きいほど、確認前に誤りが広がります。大量の成果物を最後にまとめて確認すれば、レビューする側が追いつきません。

設計、製造、テスト、修正を小さな単位で繰り返し、結果を確認してから次へ進む方が、AIの作業速度に合います。アジャイルソフトウェア開発宣言の原則も、実際に使えるソフトウェアを短い間隔で提供し、定期的に進め方を見直す姿勢を重視しています。ウォーターフォールを全面的に否定するのではなく、AIが短時間で加える変更の量に合わせて、確認と修正の間隔を短くする必要があります。

リーダーは、自分で個々の問題を解決するより、AIが作業を続けられるようにするための準備に時間を使います。次に着手するタスクを用意し、依存関係を解消し、判断が必要になる前に論点を洗い出します。成果物を一度に確認できる量に分けてレビュー担当者に渡し、重大な問題が見つかれば、影響が広がる前に止めます。平時にはAIを待たせず、有事には迷わず止める判断を含めたワークロード管理が、AI時代のリーダーには求められます。

まとめ

今後はAIが開発の中心になることが確実です。仕様、判断材料、テストデータ、実行環境を先回りして整え、AIが次の仕事へ途切れなく進める状態を保つ必要があります。

一方、AIを止めない運用は、無制限に動かすという意味ではありません。通常のエラーはAI自身で処理できるようにし、本番環境への未承認の変更や情報流出などの重大なリスクを検知した場合は、必ず停止させます。平時の継続と有事の停止を仕組みとして両立させる必要があります。

モックから正式な設計へ進む際には、リーダーがソースコードを確認し、不要な仮実装やジャンクコードを取り除きます。さらに、データモデル、業務ワークフロー、UI、API、業務要件の各観点から成果物を確認し、設計、製造、テストが同じ誤りを引き継ぐ事態を防ぎます。

AIが実装を担う範囲が広がるほど、リーダーには、個別の実装へ入る能力より、タスク、依存関係、レビュー、リスクを管理する能力が求められます。AIに渡す仕事を先回りして用意し、短い単位で設計と検証を繰り返しながら、技術、品質、進捗を一体で管理する体制を整える必要があります。

参考文献

Manage Technical Debt with SonarQube and TFS｜Microsoft Learn

How test-driven development amplifies AI success｜Google Cloud

Effective harnesses for long-running agents｜Anthropic