A2A入門：社内AIエージェント連携の設計と業務活用

カードに書く四つの項目を確認し、skillの説明に必ず入れる三つ（扱わない対象・案内する部署や規程・最終決定しないこと）を、実物のカードで見ます。

仕様で決まっている状態のうち四つを、業務の言葉へ読み替えます。モデルの抽出結果をコードで状態に変換する構造と、その限界までを扱います。

経理部と情報システム部の規程エージェントを起動し、カードを取得してから申請を1件送ります。同じ申請に対して、部署ごとに違う状態が返るところまでを扱います。

二つの部署のカード定義を並べ、入れ替わっているのが設定だけであることを確認します。依頼を受けたときに走るexecuteの分岐までを扱います。

サーバーを立てる4行と、依頼を送る側のコードを読みます。ほかのエージェントから呼べる入口が二つだけであること、Task IDとcontext IDがどう渡るかまでを扱います。

不足項目を挙げて止まる状態を実物で見ます。書き足して送り直したとき、同じTask IDで会話が続くところまでを扱います。

依頼を引き受けない状態を実物で見ます。答える側と突き返す側が、申請の内容によって入れ替わるところまでを扱います。

回答の成果物に、判定・条番号・原文を載せる設計を実物で見ます。何を確認すれば回答を点検できるかまでを扱います。

外から呼べる入口が二つだけであることを確認し、カードの公開範囲と実行APIの権限を分けて決めます。認証方式の宣言と、宣言だけでは実装されないことまでを扱います。

三段の問いで、使わないと決める条件と使うと決める条件を並べます。A2Aで減る手間と、どちらを選んでも残る運用の負担を比べ、試したあとに何を測るかまでを扱います。

照会ごとに残す6項目と、それぞれの値の出どころを確認します。残さないものと、その理由までを扱います。

深夜のタクシー代という一つの例で、つなぎ方・答える範囲・確かめ方の三つの判断を通します。試行の計画を一文にまとめ、担当外・差し戻し・根拠の誤りが起きたときに誰が何をするかが決まっているかを点検するところまでを扱います。（本編はここまで）

署名で発行元を検証する仕組み、認証方式の合意、カードの出し分け、長い処理の待ち方を扱います。本編は前の回で終わっているので、取引先との連携を検討する場面で見る回です。