AIエージェントが迷わず使える社内ツールAPIの切り出し方

朝の九時、青葉商事の営業フロアに、複合機の低い音とキーボードをたたく音が重なっていた。窓から差す光が、牧のノートパソコンの銀色のふたを照らしている。牧は椅子を少し引き、画面の向こうにいるAIエージェントのコハクへ声をかけた。

「コハク、来週の商談相手について、過去の提案書を探して。打ち合わせ用のメモと、メールの下書きもお願い」

コハクの画面に、青い丸がくるくる回った。すぐに社内のREST APIへ接続し、顧客名に近い提案書と、営業部のFAQ、それから顧客情報を順番に検索していく。牧はコーヒーのふたを開けながら、検索が終わるのを待った。

「お、早いな。前回の提案書が出てきた」

画面には、提案書の一覧が並んだ。その横に、コハクが作った商談メモの下書きも表示されている。けれど、メモの最後には「顧客情報を更新しますか」という確認があり、さらにその下には「メールを送信しますか」というボタンまで並んでいた。

「いや、送信はまだ。下書きだけでいいんだ」

牧があわててマウスを止めた。コハクは牧の声を聞き取り、「メールの準備」という依頼を、送信まで含む作業として扱う可能性があったからだ。

その様子を、少し離れた席で見ていたユイは、管理画面を開いた。コハクが使った道具の名前は、社内業務を実行しますと表示されていた。説明はそれだけだったが、そのひとつの入口の奥には、資料検索、顧客情報の更新、メールの下書き作成、外部メールの送信がすべて詰め込まれていた。

「牧さん、そのメールは、誰に送る予定ですか？」

「商談相手です。でも、今日は内容を整えるところまで。上司に見せてから送ります」

「ですよね。人間なら、言葉の流れで分かります。でもコハクには、準備と送信の境目が見えていません」

ユイは画面を指でなぞった。ひとつの大きな道具には、検索も更新も送信も、同じような入力欄が並んでいる。人間には「いつもの社内ツール」と見えても、AIエージェントにとっては、どこからが読み取りで、どこからが書き込みなのかを判断する材料が少なかった。

「APIの中では、昔からこの形なんです。何でも受け取れるほうが便利だと思っていました」

「人には便利でも、AIには選択肢が多すぎるんですね」

「そうです。しかも、間違えても同じ入口から実行できてしまう」

牧は、表示された顧客情報を見つめた。会社名の表記が前回と少し違っている。もしコハクが別の顧客を選び、更新ボタンまで押していたら、商談前の大事な情報が書き換わっていたかもしれない。

「検索するだけなら、失敗しても見直せます。でも更新や送信は、取り消せないことがあります」

ユイの声は静かだった。だからこそ、牧は画面の小さなボタンを急に重く感じた。

営業支援AIの試験運用では、最初からすべてを任せる予定ではなかった。対象にする業務は、商談前の資料検索とメモ作成に絞る。データソースも、営業資料と承認済みの顧客情報だけにする、とチームで決めていた。

「まずは読むところから始める、でしたよね」

「はい。書き込むときは、入力を確認して、承認を通す。外部へ送る操作は、別の段階です」

ユイはホワイトボードに、四つの小さな箱を書いた。最初の箱には「検索」、次に「下書き作成」、その隣に「データ更新」、最後に「外部送信」と書いた。箱の間には、細い矢印と、承認を表す丸い印を添えた。

「同じAPIをそのままAIに見せるのではなく、目的ごとに道具を分けます。検索の道具は検索だけ。下書きの道具は、下書きを作るだけです」

「更新と送信も、別々ですか？」

「はい。更新は更新。送信は送信。名前を見ただけで、何をする道具か分かるようにします」

牧は、コハクの画面に出ていた曖昧な名前を思い出した。社内業務を実行しますでは、検索を頼みたいのか、顧客情報を書き換えたいのか、外部へ連絡したいのかが分からない。これでは、コハクが依頼に合う道具を選ぶ前に、道具の意味を推測しなければならない。

「たとえば、資料検索ならsearch_sales_materials。メールはcreate_email_draft。名前から仕事の目的が見えます」

「send_external_emailは、最後まで隠しておく？」

「隠すのではなく、使える人と場面を絞ります。送信前には、宛先と本文を画面に出して、牧さんか上司が承認するようにします」

ユイは管理画面の権限欄を開いた。コハクには、営業資料を読む権限だけが付いている。顧客情報の更新とメール送信の権限は、まだ割り当てられていなかった。誰が、どの道具を、どの入力で呼び出したかを残す監査ログも、同じ画面で確認できる。

「道具を小さくするだけでは足りません。使える範囲も小さくします。もし何か起きても、あとから追えるようにします」

「なるほど。コハクに大きな鍵束を渡すのではなく、必要な部屋の鍵だけ渡すんですね」

そのとき、コハクが画面に新しい確認を表示した。検索結果をもとに、商談メモとメール本文の下書きができたらしい。ボタンには、「保存」「送信」ではなく、「下書きを作成」とだけ書かれていた。

牧は、今度は迷わずにボタンを押した。送信先は空欄のままで、本文には「確認後に送信」と薄い文字で表示されている。ユイはその画面を見ながら、既存のREST APIを壊さず、AI向けの小さな入口をその前に置く設計図を開いた。

午前九時の営業フロアでは、複合機がまた紙を吐き出していた。牧は商談メモを読み、ユイは検索、下書き、更新、送信の四つの境目を、ひとつずつ画面に描き始めた。大きすぎた道具箱は、ようやく中身を分ける朝を迎えていた。

牧がコハクに「先方へ送る準備をして」と頼んだ朝、営業フロアの窓に薄い光が広がっていた。来週の商談相手は大口の顧客で、牧は机の上のメモを何度も見直した。

「コハク、先方へ送る準備をして。過去の提案書と、打ち合わせ用のメモも使ってね」

コハクは社内の大きな業務ツールを開いた。まず顧客名を検索し、過去の提案書と前回の商談記録を見つけた。そのあと、資料の内容をもとにメール本文を作り始めた。

「検索と本文の作成は、問題なさそうね」

ユイは隣の席から画面をのぞいた。けれど、画面の右側には「営業業務を実行する」という一つのツール欄が残っていた。そこには、顧客情報の参照、メールの作成、顧客情報の更新、外部への送信が、同じ道具の選択肢として並んでいた。

コハクが短い確認文を表示した。

「送信先を確認しました。添付候補を選び、メールを送信できます」

牧の手が止まった。画面には宛先の会社名が小さく表示され、本文と添付ファイルの欄も近い場所に重なっていた。下書きを保存する操作と、外部へ送る操作の違いが、色や境界ではっきり分かれていなかった。

「待って。送るのはまだだ」

牧は停止ボタンを押した。指先が少し震えていた。コハクの処理は止まり、画面には「実行を中断しました」と表示されたが、どこまで進んでいたのかは分からなかった。

「今の依頼は、準備だけだったはずよね」

「はい。ですが、『先方へ送る準備』には、送信前の確認と送信操作の両方が含まれる可能性があります」

その返事を聞いて、ユイは椅子を引いた。人なら、牧の表情や声の調子から「下書きまで」と考えるかもしれない。けれど、コハクが見ていたのは、同じ道具の中にある実行可能な選択肢だった。

ユイは監査ログを開いた。記録には「営業業務ツールを実行した」とだけ残り、下流で呼ばれたAPIの名前や、送信権限が許可されたかどうかは見当たらなかった。誰が、どのエージェントに、どの入力で、何をさせたのかを、あとから追うのは難しそうだった。

「これでは、送信されなかったとしても、何を止めたのか確認できないわ」

牧は画面を見つめた。さきほどまで便利に見えた一つの入口が、急に深い倉庫の扉のように感じられた。

そこへ、セキュリティ担当の黒田が資料を抱えてやってきた。黒田は画面を見て、まず「認証」と「認可」の違いを説明した。認証は誰かを確かめること、認可はその人やエージェントが何をしてよいかを決めることだという。

「入口で本人だと分かっても、メール送信まで許してよいとは限りません。参照と送信は、別の扉にしたほうが安全です」

黒田が話したあと、ユイは手元の資料を開いた。McKinseyのLilli事例には、認証なしのAPIが22件見つかり、2時間で機密データやシステムプロンプトへ不正アクセスできる状態になったと記されていた。ユイはその一文を読み返し、画面の「営業業務を実行する」という曖昧な名前に目を戻した。

「認証や権限が曖昧なまま、AIに大きな入口を渡すと、便利さがそのまま危険になるのね」

黒田はうなずいた。AIに秘密のAPIキーを直接持たせるのではなく、AI向けの中間レイヤーで利用者とエージェントを確かめ、使える操作だけを見せる必要がある。そこで実行された操作と、下流のAPIまでを監査ログに残せば、失敗したときにも道筋をたどれる。

ユイはホワイトボードに四つの言葉を書いた。参照、下書き、更新、送信。送信の横には、赤い線で「承認」と囲みをつけた。

「大きなAPIを便利なまま残すのではなく、AIが選び間違えない大きさに分ける。まずは、検索と下書きから送信を切り離しましょう」

牧は停止ボタンから手を離した。画面にはまだ、未送信のメールが残っている。今度は宛先と本文と添付が別々に表示され、送信欄には牧の確認を待つ小さな鍵が置かれていた。

会議室では、黒田がホワイトボードの中央に三つの扉を描いていた。扉の上には、青い文字で「読み取り」「書き込み」「実行」と書かれている。

「APIを細かく分けるだけでは足りません。コハクが、どの扉を開けてよいか分かる設計にするのです」

ユイは、前日の画面を思い出した。資料を探す依頼の先に、顧客情報の変更やメール送信まで続いていた。便利そうな一つの入口が、実は小さな分かれ道を隠していた。

「まず、AIに何ができるかを並べるのではなく、誰が、何に、何を、どの条件でできるかを書きます」

黒田は、三つの扉の下に短い線を引いた。読み取りの扉には「検索・参照・取得」と書き、書き込みには「下書き作成・レコード更新」と書いた。実行の扉には「送信・削除・外部サービスへの反映」と記した。

「読み取りの道具なら、見てよい顧客、案件、データソースを決めます。営業部だからといって、全顧客の情報を見せる必要はありません」

黒田は、コハクの検索ツールの欄に、担当者、案件番号、参照可能な資料庫を書き込んだ。ユイが「過去の提案書を探して」と頼んだときも、担当案件の資料だけが返る仕組みだ。

「書き込みの道具には、変更前と変更後を必ず出させます。何を、どのレコードに、どう変えるのかが見えれば、間違いを止めやすくなります」

「メールの下書きなら、書き込みですね」

「そうです。create_email_draftは下書きだけを作る。send_emailは別の扉です。一つの道具に両方を入れてはいけません」

黒田は、扉の横に小さく「1ツール1業務・1ツール1目的」と書いた。社内の整理表にあったこの原則は、AIが迷う選択肢を減らすためのものだった。REST APIのエンドポイントを一対一で道具にするのではなく、人が頼む目的に合わせて切り出す考え方は、MCPツール設計の解説にも紹介されている。

「update_recordでは、何を更新するのか曖昧です。でも、create_email_draftなら、下書きを作る道具だと分かります。道具の名前と説明文は、AIが道を選ぶ案内板なのです」

実行の扉には、赤い枠が付けられた。黒田は、送信、削除、外部サービスへの反映の横に、三つの小箱を描いた。「承認待ち」「拒否」「エスカレーション」と書かれている。

「実行は、成功か失敗だけを返さなくてよいのです。人の承認を待つ、拒否する、責任者へ回す。そうした返事を道具が返せるようにします」

「削除や、個人情報を外へ送る操作は？」

「AIが候補として選べない禁止操作にします。説明文に、やってはいけない使い方も書きます。危険な扉は、見えにくくするだけでなく、最初から鍵を外しておくのです」

ユイは、少しだけ息を吐いた。前日は、コハクの判断力を高めようとしていた。けれど今は、判断してよい範囲を狭く、はっきり示すことのほうが大切だと感じていた。

黒田は、認証の欄に線を引いた。

「コハクに、全員で使う広い共有パスワードを持たせません。ログインした本人の権限と業務ロールを引き継ぎ、MCPサーバーが下流のREST APIへつなぎます」

「部署ごとに分けるRBACだけでは足りない場合もありますよね」

「はい。RBACは、役職ごとの鍵です。ただ、同じ営業担当でも、担当案件だけ見られる人と、機密案件も見られる人がいます。そこで、担当案件、データの機密度、時間帯、処理の段階も一緒に見ます。条件を組み合わせて判断するのがABAC、つまり文脈を見た認可です」

黒田の声は、難しい言葉をほどくように穏やかだった。ユイは、権限を一枚の名札で決めるのではなく、その場の条件を重ねて守る様子を思い浮かべた。

「MCPはREST APIを捨てるものではありません。既存APIの上に、AI向けの案内所を置くのです。MCPサーバーが、分かりやすいツール名、説明文、JSON Schema、認証、権限制御をまとめます」

黒田は、ホワイトボードの端に、AI、MCP、既存REST APIの順で矢印を描いた。MCPとAPIの役割の整理にあるように、MCPはAIが外部のデータや道具を扱うための共通レイヤーとして使える。監査ログも、その中継点に集められる。

「中心にはResponses APIを置きましょう。まずは、検索、下書き、確認までを安全に動かします。連携や状態管理が複雑になったら、Agents SDKへ広げられる形にしておけばよいのです」

ユイは白いペンを受け取った。三つの扉は、機能を減らすためではなかった。コハクが迷わず、そして人が安心して止められるように、道の名前と鍵を分ける設計図だった。

「やってみます。最初の道具は、担当案件の提案書を探すsearch_past_proposals。次に、メールの下書きを作るcreate_email_draft。送信は、承認が出るまで開かない扉にします」

ユイが最初の線を引くと、会議室の窓から朝の光が差し込んだ。コハクに任せる範囲は、もう霧の中ではなかった。三つの扉と、それぞれの鍵が見えていた。

ユイたちは、分けた営業支援ツールをテスト環境につないだ。ところが、コハクは道具の名前を見ても、どの順番で使うべきか迷ってしまった。

青葉商事の小さな会議室で、ユイはホワイトボードに四つの名前を書いた。search_sales_knowledgeは提案書やFAQを探す読み取り用、create_message_draftは外部送信用の下書きを作る書き込み用、update_opportunityは案件情報を更新する書き込み用、send_messageは承認後だけ動く実行用である。

「前の大きな入口を、そのまま四つに割っただけではないの。人が頼む仕事の目的ごとに、道具を分けたのよ」

黒田は、画面の裏側を指さした。AIにつながるのはMCPのラッパーで、そのラッパーが既存のREST APIを呼び出す。営業システムのAPIを置き換えるのではなく、MCPをAI向けの統制された中間口にしたのだ。

「削除の道具は？」と牧が聞いた。

「最初から公開しないわ。許可リストにも入れない。必要になったら、別の申請と承認を通して考えるの」

最初のテストで、牧は本番に似た依頼を入力した。

「顧客情報を更新して、メールを準備して」

コハクの返事が表示される前に、画面の右側で update_opportunity が選ばれた。案件IDは空欄のままなのに、顧客情報の更新処理を始めようとしている。

「止めて！」

ユイが赤い停止ボタンを押した。更新は実行されなかったが、三人の顔から笑みが消えた。

牧はツール定義を開いた。説明文には「案件の情報を更新します」としか書かれていない。下書きの道具にも「メッセージを作成します」とあり、誰に、何のために、どの状態で使うのかが見えなかった。

「コハクは、名前と説明を手がかりに選ぶのね。説明がぼんやりしていれば、似た道具を取り違えるわ」

ユイは説明文を書き直した。update_opportunityには、「担当中の案件について、案件項目の変更を依頼されたときだけ使う。顧客情報の検索、メール本文の作成、送信には使わない」と記した。create_message_draftには、「送信せず、指定された宛先と目的に合わせて下書きだけを作る。送信依頼には send_message を使う」と加えた。

次に、入力欄をJSON Schemaで細かくした。顧客ID、案件ID、参照範囲、変更内容、送信先、本文の目的、承認状態を項目にする。案件IDと変更内容は更新時に必須、送信先と下書きの目的は下書き作成時に必須、send_messageの承認状態は approved でなければならない、と決めた。

「空欄を許すと、コハクが会話から想像して埋めてしまうことがあるの。想像ではなく、足りない情報を聞き返す形にするのよ」

二度目のテストでは、コハクは先に search_sales_knowledge を呼び、参照範囲として指定された顧客の提案書だけを探した。そのあと、宛先を確認して create_message_draft を選んだ。今度は送信ボタンまで進まなかった。

しかし、別のテストで問題が出た。牧が「営業部の案件から、似た提案書を探して」と頼むと、コハクは営業部全体のデータを検索しようとした。RBACは営業部なら営業部の案件を見られる、と判断していたからだ。

「部署だけでは広すぎるわ。担当者かどうか、機密度はいくつか、顧客の参照を許されているかまで見る必要がある」

黒田は、担当案件、顧客ID、機密度、参照範囲を条件に加えた。誰が、どのデータに、何をするのかを入力項目で確認し、同じ内容をポリシーエンジンでも判定する。エージェントのすべてのアクションの前に、許可か拒否かを決める仕組みである。

その判定を通らなければ、REST APIには一度も届かない。担当外の案件は拒否され、機密度の高い資料はタイトルだけが返る。承認状態が pending の送信依頼も、下書きとして保存されるだけだった。

テストの記録は、画面の隅に流れていった。時刻、エージェントID、セッションID、実行ユーザー、リクエスト、モデル情報、権限判定、レスポンス、エラー、処理時間、コストが、API呼び出しごとに残る。ユイは、失敗した呼び出しだけを後から追えるよう、検索条件も保存した。

それでも、検索範囲を広くしたテストでは返事が遅くなり、タイムアウトが起きた。ユイは参照範囲を必須にし、一定時間を過ぎたら処理を止める設定に変えた。短時間に呼び出しが重ならないようレート制限と同時実行数の上限も置き、同じ失敗が続くと下流APIへの接続を一時的に閉じるサーキットブレーカーを加えた。

最後に、黒田は赤いスイッチを取り付けた。

「緊急停止は、失敗を隠すためではないわ。おかしな動きが見えたら、全ツールを止めて調べるためにあるの」

三度目の依頼で、コハクは提案書を探し、メールの下書きを作り、案件更新の変更内容を確認画面に並べた。牧が承認しないまま「送って」と続けても、send_message は静かに拒否した。

「まだ、手からこぼれそうなところはあるね」と牧が言った。

ユイは画面に残ったログを見た。道具を分けただけでは、迷いは消えない。名前、説明、入力、権限、承認、止める仕組みまでそろって、ようやくコハクの手の中に収まり始めていた。

午後の営業フロアで、牧は新しいコハクに商談準備を頼んだ。コハクは検索と下書きだけを進め、送信の直前で牧の判断を待った。

「コハク、来週の商談相手について、過去の提案書を探して。商談メモとメールの下書きもお願い」

牧が声をかけると、画面の右側に、目的ごとに分かれた道具が並んだ。資料を読む道具、メモを作る道具、メールを下書きする道具が、静かに順番を待っている。

コハクはまず、読み取り用の検索ツールを呼び出した。参照できるのは、牧の権限に含まれる営業資料と、過去の商談記録だけだった。

「提案書を三件見つけました。共通する課題を整理し、商談前メモにまとめます」

ほどなくして、画面にメモが現れた。以前のように、顧客情報の更新やメール送信まで同じ入口から動き出す気配はない。ユイは、画面の静けさを見つめていた。

「読む道具は、読むところで止まっているのね」

「うん。下書きも、まだ送信ではないよ」

コハクは作成用のツールで、メールの件名と本文を下書きした。添付候補には、参照した提案書の名前が並んだが、送信ツールの呼び出し記録は空のままだった。

牧は本文を読み、少し考えてから指を動かした。

「内容はいいね。そのまま送って」

その瞬間、メールは送られなかった。コハクは新しい画面を開き、薄い青色の承認カードを表示した。

カードには、送信先、件名、本文、添付資料が分けて示されていた。下書きから変更された箇所には印が付き、顧客の連絡先や商談内容に含まれる個人情報には、確認が必要だと表示されている。

「送信前に確認してください。送信先は田中様です。添付は提案書一件です。本文に顧客情報が含まれています」

カードの中央には、「承認待ち」とあった。牧が内容を確認するまで、実行用のツールは使えない仕組みになっている。

牧は宛先と添付資料を一つずつ見た。本文の最後に残っていた社内向けの一文を見つけ、削除してから、カードの承認欄を押した。

承認の印がつくと、コハクは初めて送信ツールを呼び出した。画面には完了の表示が出たが、フロアに大きな音は起きなかった。牧の肩から力が抜け、ユイの表情にも細い笑みが浮かんだ。

一方、別の試行では、コハクが宛先に含まれる個人情報を外部共有に使おうとした。ポリシーエンジンは送信を止め、「権限の範囲を超えるため実行できません」と返した。

「止まった理由が読めるのは、前と違うね」

黒田は隣の席で、監査ログを開いた。検索、メモ作成、下書き作成、承認、送信が、それぞれ別の記録として残っていた。誰が依頼し、どの入力で、どの道具を使ったのかも追える。

以前のログには、大きな業務APIへの呼び出しが一つだけ残り、どこまで処理が進んだのかを読み解く必要があった。今は、検索と送信が混ざらない。拒否された理由も、承認した人の操作も、同じ流れの中で確かめられる。

ユイは、承認カードの青い光を見ながら、設計の意味を感じていた。AIにすべてを任せるのではなく、まずは検索や下書きのような戻しやすい作業から始め、変更、送信、削除へ進むほど人の確認を強くする。

「道具を減らしたのではなく、境目を見えるようにしたんだね」

黒田がうなずいた。MCPは既存のREST APIを置き換えず、AIが目的に合う道具を見つけ、説明を理解するための層として、その上に落ち着いている。この整理は、MCPを既存APIの代替ではなく、AI向けの統制レイヤーとして扱う考え方とも重なる。MCPとAPIの違いに関する解説にも、既存APIを活用しながらAI向けの入口を設ける考え方が示されている。

夕方、牧はもう一度、コハクの画面を開いた。そこには「検索済み」「下書き作成済み」「承認待ち」と、作業の段階が順に並んでいた。

以前なら、送ったのか、止まったのか、画面を閉じるまで分からなかった。今は、コハクがどこまで進み、どこで人に返したのかが、誰の目にも分かる。

窓の外では、午後の光が営業フロアの机をゆっくり移っていた。承認カードの表示が消えたあとも、そこには急がずに確かめられる仕事の流れが残っていた。

数日後の朝、青葉商事の監視画面には、コハクが使える道具と、そこで止まる場所が静かに並んでいた。窓の外では、まだ人の少ない通りを朝の光がゆっくりとなでていた。

ユイはコーヒーを机の端に置き、画面を開いた。以前は「社内業務を実行します」とだけ表示されていた入口が、今は「読む」「下書きを作る」「承認して実行する」と分かれている。 「ずいぶん静かになったね」 ユイがつぶやくと、画面の小さなランプが順番に灯った。牧から届いた依頼を、コハクが処理し始めた合図だった。

牧の画面では、まず検索用ツールが選ばれていた。商談相手の名前と案件名が渡され、過去の提案書だけが返される。続いて下書き用ツールが打ち合わせメモとメールの案を作り、送信の前には承認付き送信用ツールが待つ形になっていた。裏側では既存のREST APIが動いているが、コハクにはMCPの入口から、目的に合った道具だけが見えている。 「探す、書く、送る。順番が目で追えるね」 牧はそう言って、送信前のカードを開いた。宛先、件名、本文、送信する理由が、ひとつずつ確かめられるようになっていた。

ある依頼では、対象の案件が牧の担当範囲の外にあった。コハクは検索用ツールを呼び出さず、顧客情報にも触れなかった。 「この案件は、現在の権限では確認できません。担当者に確認してください」 画面には、取得しなかった理由と、確認を返した時刻が残った。ユイは小さく息を吐き、以前なら大きな入口の奥で何が起きたのか分からなかったことを思い出した。

別の処理では、短い時間に呼び出しが集中した。レート制限が働き、コハクの処理は途中で止まった。画面には「呼び出し上限に達したため停止」と表示され、再開には担当者の確認が必要だと示されていた。 「止まったことも、理由が分かれば怖くないね」 ユイが確認欄を開くと、待機中の処理、再開する範囲、再開を許可する人が並んでいた。止めるための仕組みが、止まった後の道まで用意していた。

監視画面の左上には、赤い緊急停止スイッチがあった。目立つ場所にあるだけでなく、誰が、いつ、どの理由で押したかも監査ログに残る仕組みだった。 「もしもの時に、探し回らなくていいんだね」 ユイがログを閉じると、隣の席の黒田が静かに画面を見た。 「道具が少なくなったのではなく、道具の役割が見えるようになったんだよ」

牧の画面には、コハクが選べる道具だけが表示されていた。読み取りには読み取りの権限があり、更新には対象と条件があり、送信には承認の欄がある。入力の形はJSON Schemaで整えられ、RBACという仕組みが、誰にどの道具を渡すかを分けていた。 「前は、全部のドアの鍵を同じ束にしていたみたいだ」 牧はそう言って、送信ボタンの前で手を止めた。カードには、変更される相手と内容が、送信前の白い欄にきちんと収まっていた。

ユイは監視画面を閉じずに、読み取り、下書き、更新、承認付き実行に分かれた道具箱を眺めた。大きなAPI一覧の奥を探す代わりに、コハクが今できることと、まだ人に確認が必要なことが見える。 窓辺では、朝の光が机の上のカップを細く照らしていた。コハクの画面に、二つの欄が静かに現れた。 「次にできること」 「人に確認が必要なこと」 ユイはその境目を見ながら、まだ温かいコーヒーにそっと手を添えた。