【ITニュース解説】We let agents run the boring half of our projects. They ask better questions than we did

プロジェクトの開発は、大きく二つの段階に分けられる。前半は、会議を開き、ワークショップで話し合い、仕様書を作成し、関係者間で合意を形成する「話す」段階である。ここでは多くの人が参加し、議論を通じて共通理解を深めることが重要となる。しかし、この段階でいくら綿密な計画を立て、合意を形成しても、次の「作る」段階で問題が生じることが少なくない。

プロジェクトの後半は、合意された内容を具体的なタスク（チケット）に分解し、それをコードに落とし込んでいく「作る」段階だ。この段階に入ると、すべての指示は明確で具体的なものでなければならない。「売り手が通知されるべきだ」という漠然とした仕様はコードには変換できない。例えば、「購入が完了したら、売り手の登録メールアドレスに注文詳細と発送方法に関する案内を送信する」といった具体的な指示が必要になる。

この「合意された内容」と「具体的な実装」の間には、しばしば大きなギャップが生じる。開発者が仕様の曖昧さに直面し、実装方法について疑問を抱いたり、あるいは疑問そのものに気づかなかったりすることがある。もし疑問が解消されずに開発が進めば、開発者は不明確な仕様に基づいて自己判断で実装を進めてしまい、結果として意図しない動作や品質の低いプロダクトが生まれてしまう。このような状況では、開発の遅延や品質の低下を招き、プロジェクトが停滞する原因となるのだ。また、人間が手作業でチケットを作成したり、コードを実装したりする場合、個人の経験や判断によって一貫性が失われ、作業の品質にばらつきが生じることも問題となる。

このギャップを埋め、開発プロセスを効率化するために導入されたのが、AIを活用したエージェントワークフローである。これは、特に「話す」段階から「作る」段階への移行をスムーズにし、技術的な側面からプロジェクト管理を支援することを目的としている。

このワークフローの中核をなす最初のスキルは「/feature」と呼ばれるものだ。これは、開発しようとしている機能について、未決定の事項や潜在的な衝突をAIが徹底的に質問することで、詳細な仕様を明確にする。AIは一つずつ質問を投げかけ、全ての疑問が解消されるまでそれを続ける。このプロセスによって、人間が見落としていたバグの可能性や、誰も気づかなかった未解決の疑問が表面化することが多く、結果として不完全なアイデアや漠然とした仕様が排除される。例えば、「買い手と売り手の間でこのルールは対称的か？」や「部分的な返金後もこのガードは適用されるか？」といった、開発者が一人で判断しがちな小さな疑問も、AIの質問によって明確にされ、プロジェクトチームで合意形成される。これにより、以前はレビュー段階や本番環境で発覚していた問題が、コードを一行も書く前に質問として顕在化するようになる。

「/feature」の成功を受け、さらに一歩進んだ「/jira」スキルが開発された。これは、研究、計画、実装という一般的なAI開発のフローを取り入れたもので、Jiraチケットを入力として受け取り、「/feature」スキルを使って詳細な仕様を詰めた後、複数のサブエージェントに実装作業を指示する。このプロセスでは、Gitのワークツリーを利用し、各チケットに専用の作業環境を用意することで、複数のタスクを並行して進めることが可能になった。さらに、実装、レビュー、再実装というレビューサイクルを繰り返し行い、それぞれの段階で新たなエージェントを投入することで、以前の判断による先入観を排除し、コードの品質を高めている。このようにして、開発者はコードを直接書くよりも、エージェントの作業を調整し、指示を与える「オーケストレーター」としての役割を担うようになる。最終的には、「/create-pr」スキルによって、レビューア向けの「何を行い、なぜ行ったか」を記述したプルリクエストのドラフトが自動生成される。

プロジェクトが大規模になるにつれて、今度はプロジェクト全体の仕様とコードベースの同期が課題となった。数多くの仕様書や設計図、会議の議事録が存在する中で、「過去24時間に何が変わったのか」「どの仕様が更新されたのか」「コードと仕様の間に不一致はないか」といった日々の状況把握が困難になる。そこで登場したのが「/breakdown」スキルである。このスキルは、プロジェクトの仕様書（ConfluenceページやLucidchart、Figmaのリンクなど）をAIが読み取れる形式で専用のフォルダにコピーし、常に最新の状態に同期する。毎回の実行で、仕様書の変更点が検出され、誰がいつ変更したかまで報告される。もしコードと仕様の間に不一致があれば、AIはそれを指摘し、仕様書が真のソースであるべきことを主張する。例えば、「すべてのメールに『5営業日』と書かれているのに、仕様書では『1-5銀行営業日』となっている」といった場合、AIはPO（プロダクトオーナー）に対し、仕様書を更新して真実のソースとすることを促す。このスキルは、長時間にわたるブレイクダウンセッションを大幅に削減し、自動的にJiraチケットを生成するまでになった。これにより、プロジェクトのタスクの約70%が効率的に処理され、陳腐化したタスクが早期に発見されるようになった。

日常業務を支援するスキルとして、「/standup」も開発された。これは、自身の未完了のプルリクエスト、レビュー依頼、Jira課題、ローカルの作業環境、プロジェクトフォルダを統合し、それぞれの間の不一致を自動的に検知して修正を提案する。例えば、Jiraのチケットが「ToDo」ステータスなのに、関連するブランチにコミットが存在する場合など、プロジェクトの状態と実際の作業の「ズレ」を指摘し、一括で修正する手助けをする。

この一連のワークフローにおいて、人間が介入し、最終的な判断を下すポイントは三つある。一つは「/feature」による徹底的なヒアリングで、未決定の設計上の意思決定に対して人間が回答する時点。二つ目は「/breakdown」で自動生成されたJiraチケットを承認する時点。そして三つ目は、コードの実装とレビューのループが完了し、作者が最終的な承認を与える時点である。これら以外の反復的で「退屈な」作業は、ほとんどAIが自動的に実行する。つまり、AIはプロジェクトの「作る」段階におけるルーティンワークや詳細の詰めを効率化し、人間はプロジェクトの全体的な方向性を決定したり、AIが対応できない複雑な問題解決や創造的な作業、そして最終的な責任を負うという、より戦略的な役割に集中できるようになったのだ。

このアプローチは特定のAIツールに限定されるものではなく、汎用的な設計原則に基づいている。実装前に徹底的にヒアリングを行うこと、未解決の疑問は必ず責任者に確認すること、チケット作成と実装のプロセスを一貫させること、そして仕様書をAIが比較・同期できる形で管理することなどが挙げられる。特に重要なのは、常に「仕様書が真実のソース」であるという原則を徹底することだ。

最終的に、このワークフローは、チームメンバー間のプロジェクト理解のズレを防ぎ、開発チームとプロジェクトチーム間のコミュニケーション課題を解決することを目指している。AIにコードやコードベースの深い知識を活用させ、反復的な作業を任せることで、人間はより本質的な問題解決や、チーム全体の連携強化に注力できるようになる。これは、単に新しいものを開発するだけでなく、既存の複雑なシステムに適切に統合していく上で極めて重要な要素となる。