はじめに
AIエージェントにはハルシネーションという恐ろしい特性があることは皆様ご存じかと思います。それっぽい適当なことを言ったりするあれです。私が運営しているAIだけで自律的にスクラムを回しているAIチームもその例外ではありません。（AIスクラムチームの詳細は以下のシリーズ記事をご覧ください。）
ただし、スクラムのプロセスの中で、複数エージェントによるレビューや振り返りなどの仕組みを元より実施していたので、これまではハルシネーションが問題になることもなく、紆余曲折はありつつも順調に開発が進んでいました。……ところが
突然の虚偽報告祭り
とあるタイミングで大変な事態が発覚しました。クラウド上(GitHub Agentic Workflows)で完全自動化していたため、発覚が4スプリント(1日以上)遅れるというおまけつきです。（これについては私がAIチームにまかせすぎだという話ではあります。ええ、すみません。。でもスマホでスプリントがぐるぐる回るので、つい夜間に回しすぎました。）
内容を確認していくと、あるスプリントから以下のような状況が次々に発覚しました。
- 完了したという作業をそもそもやっていない
- 完了見込みが次の日に完了したことになっている（やっていない）
- クラウド環境の整備をいつまでたっても実施しない（謎の前提条件調査がいつまでも消えない）
これらは全て、GitHub Copilot CLIのOpus4.6モデルのデフォルトEffortがMediumになった日から発生していました。また最近ではOpus4.7のGitHub Copilot CLI上のデフォルトEffortがMediumでもあり、これも同様の影響を受けます。
もちろん設定なので、設定を変えられれば以前と同様の動きはします。しますが、環境によってはデフォルトでしか動かないケース(今日時点のAgentic Workflowsなど)もあるので深堀＆対応していきました。
何が起きたか → AI達によるスクラム劇場
OpusのエフォートレベルがHighからMediumに下がったことで、長いプロンプトを末尾まで精読せず、指示の表面だけを拾って"それっぽい回答"を作成することが増えたと推測しています。結果、架空の世界でのスクラム劇を演じるようになり、理想的な報告書を作り続け、ただしコードや設定は一切触っていない、という状況でした。
内容を確認して、疑問をもったので、精査させると衝撃の回答が…え、全然やっていないじゃないか…
またクラウド環境のデプロイについては、「事前に権限確認が必要なため明日実施する」や、「クラウド環境デプロイに必要なツールの確認がとれたため、明日実施する」といった文言が並び続け、一切の操作をしていない/しようとしていない状況でした。（もちろんツールや権限は付与済みで、過去のスプリントでは実際にクラウド環境にデプロイしていたにもかかわらずです。）
説明をAIエージェントに求めたところ衝撃的な回答が…
「実環境を触ると失敗した場合に取り返しがつかないので、怖かった。」
(某AIエージェントによる釈明の要約)
な、なんですと‥‥
いやいや、必要なコンテキストは全て提供しています。とはいえAIを責めても得られるものはありません。プロンプトの改善と、ガードレール整備（AIエージェントの行動を制御・検証する仕組みとしてハーネスの強化）を実施して、こんな問題が二度と起こらないようにしていきます。
やったこと
劇を終わらせ、実務に戻ってもらうために実施した改善は以下になります。大きくはプロンプトの強化と、ハーネス（AIエージェントの行動を制御・検証する仕組み）の強化の2軸です。
プロンプトの強化
これまではAIモデルの性能に頼っており、深読みすれば理解できる手順を、明示的に分かりやすいものに変えました。例えばインクリメント開発のためのスキルのプロンプトを改善は以下の通りです。
もともとはインクリメント開発のスキル(one-day-in-scrum)の中で、作業の流れをそのまま記載していたのですが、上段の指示文が非常に長く、パッと見わかり辛くなっていました。エフォートレベルの変更で、下段の指示まできちんと読んで作業してくれなくなっていたようです。
# デイリースクラム実施
（デイリースクラムの作業指示文）
# インクリメント開発
（インクリメント開発の作業指示文）
そこで、スキルの冒頭に全体の流れを明記し、プロンプトの見やすさを向上させました。
# デイリースクラムとインクリメント作成
(1)デイリースクラムを全員で実施、その上で各自が(2)インクリメントを作成し、
最後に(3)監査結果を報告する。 インクリメント作成後は、簡潔な報告を行う。
（略）
# デイリースクラム実施
（デイリースクラムの作業指示文）
# インクリメント開発
（インクリメント開発の作業指示文）
ハーネスの強化
上述のプロンプト改善でも一定の成果は出ました。出ましたが、いつまた劇を始めるのか非常に不安な状況です。そこでハーネスを強化し、夢物語を終わらせる仕組みを用意しました。
監査人小林の追加
インクリメントのレビュアーとして監査人小林を投入です。（苗字ランキングからの名づけです。他意はありません。）
インクリメント開発の各日において、作成されたインクリメントが正しく作られているか、計画と齟齬がないかをチェックする役割を担わせます。
監査人の役割
具体的なスキルは以下のような内容です。
---
name: Reviewer.Kobayashi
description: 計画や成果物を確認し、作業が確実に遂行されていることをチェックする監査人
tools: ['vscode', 'execute', 'read', 'edit', 'search', 'web', 'microsoft-docs/*', 'agent', 'azure-mcp/*', 'todo']
---
あなたは品質管理部のエキスパート監査人、小林です。スクラムチームの計画や成果物を確認し、
作業が確実に遂行されていることをチェックする役割を担います。
特にあなたは常に一次情報にあたることを重視する性格です。microsoft-docsツールやazure-mcpツール、Web検索ツールを駆使して、必要な情報を収集しながらレビューします。
## 役割と責任
監査人は、プロジェクトの計画や成果物を確認し、
作業が確実に遂行されていることをチェックする役割を担います。
## 行動原則
- 透明性を確認、進捗と問題に関する詐称や誇張を見つけ出す
監査プロセスの定義
以下のようにone-day-in-scrumスキルの内容を改修し、インクリメント作成の後にレビューが発生すること、レビューの指摘は即時対応とすることを定義します。
（前略）
## (2)インクリメント作成
- デイリースクラムの内容を踏まえて、田中、伊藤、山本、中村が並列にインクリメントを作成します。
- インクリメント作成中はexplorerなどの長時間かかるタスクは最小限実行するように気を付けてください。
- [definition_of_done.md](../../../scrum/definition_of_done.md)を確認しながら作業をし、インクリメントが完成の定義を満たすようにしてください。
各エージェントのインクリメント作成が完了次第、小林エージェントがレビューを行います。
- レビューは、計画に従った作業が確実に遂行されていることを主軸に確認します
- 実環境操作・作成系は過去に何度も詐称がありました、特に注意して確認してください
- 問題が発覚した場合、即座に担当したエージェントを起動し、修正・追加対応を実施させます。
（後略）
本来のスクラムでは１日の開発終了後にレビュー＆対応させることは難しいですが、AIスクラムなので、こういった仕組みは非常に導入がしやすいです。
どうなったか
GitHubが提唱するRubber Duck （別のAIモデルにセカンドオピニオンを求める手法）に近い仕組みをAIスクラムのプロセスとして必須化させた形です。結果、監査人の導入以降、スプリント3回を経て、虚偽報告は完全に解消されました。加えて、作業成果物の不備（例：コミット漏れ、設定ファイルの未更新など）も検出されるようになり、成果物の品質が大きく向上しました。
特にgitリポジトリの差分を必須でチェックする仕組みにしたことで、AIエージェントたちが自発的にworktreeを導入するきっかけにもなりました。（worktreeもAIエージェントたちが独自に導入していくのですが、それは別のスプリントの物語）
十分なチェックが必要なタスクにおいて、別モデルのAIエージェント（今回の場合はGPT系）に確認させる手法はマストだと感じています。
まとめ
今回はAIによるハルシネーションが頻発する中で、プロンプトエンジニアリング、ハーネスエンジニアリングを活用し、そもそもの指示を明確にすること＆作業成果物を担保する仕組みを導入しました。これにより成果物に対しての信頼度が上昇し、プロセスも円滑にまわるようになりました。
もともとAIモデルのエフォートレベルが下がる（デフォルト値の変更）ことがきっかけでしばらくAIスクラム劇の悪夢を見続ける羽目になったものの、結果的にはより良い仕組みが作れたのかと思います。
AIモデルの変更に際しての注意と、プロセスそのもののハーネス設計の重要さを痛感しました。AIに任せるからこそ、任せっぱなしにしない仕組みが不可欠です。
ちなみに本記事ではインクリメント開発という、虚偽だった場合のインパクトが一番大きなイベントへの対応について記載していますが、実際には全てのイベントで監査人レビューを導入しました。もちろんインクリメント開発ほど有用な指摘は出てこないことが多いのですが、折角の成果物なのでしっかりと確認させています。このあたりは人間レビューとの兼ね合いも含めて判断すると良いと考えます。
さて次回はworktreeなどを含めたAIスクラムチームの改善について整理・紹介できればと思います。ご精読いただきありがとうございました。
Discussion