【ITニュース解説】A coding agent can request a discount. Who gets to approve it?

現代のITシステムでは、AIなどの「コーディングエージェント」と呼ばれる自動化されたプログラムが、さまざまなビジネス処理を担うようになっている。例えば、顧客からの問い合わせに対応したり、データの分析を行ったり、さらには今回取り上げるような、割引の申請といったビジネス上の決定を提案することもある。このような自動化が進む中で、システムが提案した内容が本当に実行されて良いのか、誰が最終的な判断を下すのかという「承認プロセス」が非常に重要になる。特にシステムを開発する上で大切なのは、正しい決定がなされたときだけでなく、何らかの理由で決定が「拒否」されたときも、そのプロセスが適切に処理され、記録されることを確認することである。

この記事は、コーディングエージェントが顧客からの割引要求をシステムに提出した際、その承認がどのように行われ、どのようなルールに基づいて判断が下されるのかを具体的に示す。そして、この承認ルールが、許可された場合と拒否された場合の両方で正しく機能することを、テストを通じて確認することの重要性を強調する。 この検証には、「Accordo（アコルド）」というオープンソースのフレームワークが使用される。Accordoは、企業が顧客関係管理（CRM）システムのような、顧客とのやり取りを管理するカスタムシステムを構築する際に役立つツールである。開発者はこのフレームワークを使うことで、ビジネスのルールやポリシーをコードとして実装し、それが期待通りに動作するかを検証できる。

記事では、具体的なシナリオとして、架空の顧客がエンタープライズプランの30シートを契約しようとし、その際に25%の割引を要求する例が挙げられている。企業にはすでに割引に関するポリシーが存在する。このポリシーは、10%までの割引要求であれば自動的に承認されるが、10%を超え、50%までの割引要求については、人間の担当者による承認が必要となる。50%を超える割引は許可されない、というビジネスルールが設定されていると理解できる。今回の顧客の要求は25%オフなので、このポリシーに基づけば、自動承認ではなく、人間の担当者による承認が必要となるケースに該当する。

システムエンジニアがこのようなビジネスルールが組み込まれたシステムを開発し、テストするには、実際にそのシステムを動かして挙動を確認する必要がある。記事では、読者が自分のパソコンでこのデモを再現するための手順が詳細に示されている。Gitというバージョン管理ツール、Node.jsというJavaScriptの実行環境、そしてnpmというパッケージ管理ツールが揃っていれば、指定されたリポジトリをダウンロードし、特定のバージョンのコードを使い、スクリプトを実行することで、この承認プロセスをローカル環境でシミュレーションできる。 このスクリプトは、一時的なサーバーを自分のパソコン内に立ち上げ、そのサーバーに対してWebサービスのようにリクエストを送り、システムの内部処理を再現する。このとき、外部のサービスに接続することなく、あらかじめ用意されたデータ（カタログなど）を使って、ビジネスプロセス全体をテストできるようになっている。

デモの実行スクリプトには、各処理段階でのシステムの状態や結果を検証するための「アサーション」という仕組みが含まれている。これは、プログラムが期待通りの結果を出しているかを自動的にチェックするもので、開発において非常に重要な役割を果たす。 まず、システムは割引適用後の価格を計算する。記事の例では、初期費用3,750ユーロ、月額費用2,400ユーロと算出される。次に、割引申請がシステムに提出されると、「保留中（pending_approval）」の状態になる。この際、ポリシーバージョン1という特定のビジネスルールが適用された時点の商取引情報が「スナップショット」として保存され、後から変更されないようになっている。 ここで重要なのが、シミュレーションされたコーディングエージェントが25%の割引承認をリクエストする場面である。前述のポリシーでは10%を超える割引は人間の承認が必要なので、システムは「人間の承認が必要です（HUMAN_APPROVAL_REQUIRED）」という理由でHTTP 403エラー（アクセス拒否）を返す。この時点では、割引申請は承認されず、システムにはビジネス上の監査記録も追加されない。これが「拒否」のシナリオである。 その後、シミュレーションされた「ユーザー」（つまり人間の担当者）がこの割引を承認する操作を行うと、ようやく割引申請は「承認済み（approved）」の状態に変わる。この「承認」の際には、誰がいつ承認したかというユーザーの決定記録と、その一連のプロセスが完了したことを示す追跡記録（トレース）がシステムに記録される。 この一連の流れで特に強調されているのが、「拒否された場合にも、その失敗した試みが記録されるべきだ」という点である。成功した承認だけを記録するのではなく、なぜ承認されなかったのか、どのような理由で拒否されたのか、その経緯も追跡可能にしておくことで、システムの透明性や監査能力が高まる。拒否された試みにも失敗したトレースが残り、これにより、ビジネス上の決定が「なかったこと」にされるのではなく、適切なプロセスが踏まれた証拠が残される。

デモを実行した後、開発者はシステムが生成した記録を確認できる。具体的には、my-quote-crmというディレクトリ内に作成されるdata/quote-approval-receipt.jsonというファイルである。このファイルには、コーディングエージェントによる割引申請の拒否、その拒否の経緯を示すトレース記録、人間のユーザーによる承認決定、人間の監査記録、そして承認に至るまでのトレースなど、プロセス全体の詳細な情報が含まれる。これらの記録は、見積もり、バージョン、承認といった識別子によって互いに関連付けられているため、一連の流れをたどることが容易である。また、どのバージョンの実装が使われたかを示す情報も記録されており、後から検証する際の信頼性を高める。 さらに、ローカルデータベースとしてdata/accordo.sqliteファイルも生成され、ここにも詳細な情報が保存される。これにより、開発者はシステムがどのようにデータを処理し、保存しているかを内部から確認できる。

記事で紹介されているデモは、あくまで開発者がビジネスロジックをテストし、フレームワークの機能を理解するためのシミュレーションである。実際のビジネス環境でこのシステムを運用する際には、本物のユーザー認証や、誰がどの承認権限を持っているかといった詳細な設定が必須となる。デモでは「セールスマネージャー承認キー」といったラベルが使われるが、これはあくまでシミュレーション上の役割であり、実際の認証されたユーザーを示すものではない。 Accordoフレームワークのメリットは、ベンダーが提供するソースコードを開発者が自由に確認し、ビジネスルールを自社の要件に合わせて調整・変更できる点にある。これにより、企業は特定のニーズに合わせた柔軟なシステムを構築しながらも、承認ルールの厳密なチェック機構を維持できる。 記事の最後では、実際の見積もりや承認プロセスを持つ企業を対象に、このAccordoを使ったパイロットプログラムを募集していることが述べられている。これは、技術的なデモンストレーションが、現実世界のビジネス課題を解決するための具体的なソリューションへと繋がる可能性を示唆している。システムエンジニアにとって、このように技術がビジネスプロセスにどのように組み込まれ、価値を生み出すのかを理解することは非常に重要である。