【ITニュース解説】Require a Job Receipt. Apply Nothing the Schema Cannot Parse.

最近、ソフトウェア開発の現場では、人工知能（AI）がコードを生成する能力が目覚ましい進歩を遂げている。しかし、AIが生成したコードをそのままプロジェクトに組み込むことには、まだ多くの課題がある。AIが無制限にコードを生成することは容易だが、それを人間が適切に「検査」するプロセスが追いついていないのが現状だ。特に、AIが提案する変更を目視で確認したり、チャットウィンドウに表示されたコードをコピペしたりするだけでは、見落としや不整合が生じやすく、信頼性が低いという問題がある。

この課題を解決するために提案されているのが、「領収書（receipt）」という新しいアプローチだ。これは、AIが生成したコードの変更提案を、特定のルールに従ったJSON形式の「領収書」として受け取り、これを自動で検証する仕組みを導入するという考え方である。この「領収書」は、コードの変更が安全かつ意図した通りに行われたことを示す証明書のような役割を果たす。この仕組みを継続的インテグレーション（CI）などの開発プロセスに組み込むことで、AIが生成したコードに対する信頼性を高め、人間が変更内容をいちいち細かくチェックする手間を減らすことができる。

このワークフローは主に五つの要素から構成される。第一に、AIに作業を依頼する際の「契約書」となるjob_envelope.jsonだ。これは、AIが行うべきタスクの内容、変更を許可するファイルの一覧、そして変更後に実行すべきテストコマンドなどを明記したJSONファイルである。このファイルが、AIとのやり取りにおける真実の情報源となるため、チャットでの曖昧な指示ではなく、このファイルで明確にルールを定義することが重要だ。例えば、重要な設定ファイルや秘密情報を含むファイルをAIに触らせないように、許可リスト（allowlist）で制限をかけることができる。

第二に、AIから受け取る「領収書」の形式を厳密に定義するreceipt.schema.jsonというJSONスキーマファイルがある。このスキーマは、領収書に含めるべき必須項目（例えば、ジョブID、ステータス、変更されたファイルリスト、テストコマンド、実際のパッチ、メモなど）や、それぞれの項目のデータ型、文字数、許容される値の範囲などを細かく規定する。特に重要なのは、additionalProperties: falseという設定だ。これにより、スキーマで定義されていない余計なフィールドが領収書に含まれることを防ぎ、AIが勝手に予期せぬ情報を追加したり、場合によってはシステムの構成に関わるファイルを指定したりするリスクを排除する。

第三に、この領収書検証システムが正しく機能するかどうかを確認するためのサンプルデータ、つまりfixtures/receipt.valid.jsonとfixtures/receipt.invalid.jsonだ。前者はスキーマに適合し、かつ想定されるすべてのチェックをパスする有効な領収書の例であり、後者は意図的にスキーマ違反やその他のチェックで失敗するように作成された無効な領収書の例である。これらのサンプルを使うことで、後述する検証スクリプトが、有効なものを「有効」と判断し、無効なものを「無効」と正しく判断できるかをテストできる。

第四に、これらのルールに基づいてAIからの領収書を自動で検証するPythonスクリプトverify_receipt.pyが挙げられる。このスクリプトは、jsonschemaライブラリを利用して、まず領収書がreceipt.schema.jsonで定義された形式に合致しているかをチェックする。さらに、job_envelope.jsonに記載されたジョブIDやテストコマンドが、領収書に記載されたものと一致するかを確認する。最も重要なのは、領収書に記載された変更対象ファイルが、エンベロープで定義された許可リストに含まれているか、そして実際のパッチ（差分情報）に含まれるファイルパスも許可リスト外ではないかを厳しくチェックすることだ。これらのチェックのいずれかに失敗した場合、スクリプトはエラーを返し、領収書は拒否される。この検証スクリプトが正しく機能すること、特に無効な領収書を必ず拒否することが、このワークフローの信頼性の根幹を成す。

最後に、これらのステップを自動化し、各ステージが意図した通りに検証されることを保証するためのMakefileがある。Makefileは、エンベロープの検証、スキーマの検証、フィクスチャの検証、そして検証スクリプトによる有効・無効な領収書のテスト実行といった各ステージのコマンドを定義する。これにより、開発者は一連の検証プロセスを簡単に実行し、もし途中で問題が発生した場合でも、どのステップでエラーが起きたのかを明確に把握できる。

このワークフロー全体の目的は、AIが生成したコードが「正しい」ことを直接保証するのではなく、「検査可能」であることを保証することにある。つまり、AIからの提案が定められた形式に則っており、システムに危険を及ぼす可能性のある変更を含んでいないことを自動的に確認する。領収書が検証をパスした後、そのパッチを実際にローカル環境に適用し、エンベロープで定義されたテストコマンドを実行することで、コードが期待通りに動作するかどうかを確認する。もしテストが失敗しても、それは領収書が「検査可能」であるという事実とは矛盾しない。最終的に、有効な領収書とそれに伴うパッチは、Gitのようなバージョン管理システムにコミットされる。これにより、AIが行った変更履歴が明確に残され、将来の監査や問題発生時の追跡が容易になる。チャットの履歴は時間の経過とともに流れてしまうが、Gitに保存されたJSON形式の領収書は、信頼できる監査証跡となるのだ。

もちろん、このアプローチにも限界はある。このシステムは領収書の「形」が正しいことを保証するが、パッチの内容が論理的に「正しい」ことまでを証明するわけではない。完璧に整形された間違ったパッチであっても、スキーマ検証をパスしてしまう可能性はある。また、パッチの解析に用いる正規表現は単純なものであり、ファイルの削除や名前変更といった複雑な操作には対応できない場合もある。さらに、additionalProperties: falseの設定はスキーマの変更に影響を与えるため、スキーマのバージョン管理が重要となる。セキュリティ面では、AIに渡すjob_envelope.jsonに秘密情報を含めたり、AIにシステムの重要部分へのアクセスを許可したりしてはならない。このワークフローは、AIが生成するコードをより安全に、そして効率的に開発プロセスに組み込むための一歩を提供するものであり、AIに何でも任せて良いというわけではない。ベンダーのSLAが必要な場合や、AIにデプロイ作業をさせるような場合には、このアプローチだけでは不十分だ。しかし、AIの提案を自動的に検証し、開発者の負担を軽減したいと考えるエンジニアにとっては、非常に有効な手段となるだろう。