「注文した商品を交換してほしい」。そんな問い合わせに、AIが丁寧な返事を用意してくれる。交換条件も調べ、担当者が行う作業まで書き出してくれる。それでも最後は、人間が管理画面を開き、注文を探し、情報を書き換えている。

ここに、AI活用を考えるうえで見落としやすい境目があります。顧客が求めているのは、交換方法を知ることだけではありません。実際に商品を交換してもらうことです。回答を作る仕事と、依頼を処理する仕事の間には、システムを操作する工程が残っています。

AIにそこまで任せたいなら、モデルの賢さとともに、社内システムに何を用意するかを考える必要があります。その中心にあるのが、APIです。

システムの使い手が変われば、開発の優先順位も変わる

これまで業務システムを作るとき、私たちは人間が画面を操作する場面を思い描いてきました。必要な情報を見つけやすくし、入力を減らし、押し間違えない場所にボタンを置く。UI、つまりユーザーインターフェースを磨くことは、そのまま仕事のしやすさにつながっていました。

この前提で考えると、画面から一通りの仕事ができれば、システムは完成したように見えます。外部から機能を呼び出す窓口は、連携が必要になったら作るものとして、後回しにもできました。

ところが、日々の検索や入力、更新をAIが担うなら、システムの使われ方が変わります。人間には便利な画面でも、AIから必要な情報を取得し、操作を実行する経路がなければ、仕事を引き渡せません。

API（Application Programming Interface）は、ソフトウェア同士が機能やデータをやり取りするための窓口です。注文番号を渡して注文情報を受け取る、変更内容を渡して配送先を更新する。人間が画面上で行っている操作を、別のソフトウェアから呼び出せるようにします。

少し大胆に言えば、APIは「AIにとってのUI」です。これまで人間が使いやすい入口を用意してきたのと同じように、AIが仕事をするための入口を用意する。その意味で、APIは将来の連携に備える追加機能から、いま業務をAIに任せるための基盤へと、優先度が上がっています。

人間が状況を把握し、判断し、例外に対応するためのUIは、これからも必要です。そのうえで、AIへの移管を目指す業務では、次の入力画面を作る前に、その操作自体を誰が担うのかを考えたい。まずAPIを整え、人間の確認や例外対応に必要なUIを設計する。開発の優先順位を、そう組み替える時期に来ています。

APIは、UI・CLI・MCPの下で仕事を支える

APIを整える価値は、一つのAI機能を動かせることにとどまりません。同じ業務操作を、異なる入口から使えるようになることにもあります。

たとえば、注文の配送先を変更する機能を考えてみます。人間は管理画面から、開発者はCLIと呼ばれるコマンド入力の道具から、AIは接続されたツールから操作する。入口ごとに処理を作り直すのではなく、その下に共通のAPIを置けば、変更できる項目や入力の検証などをまとめて扱いやすくなります。

ここでよく話題になるのが、MCP（Model Context Protocol）です。AIが使える情報やツールを共通の形式で公開するためのプロトコルで、公式仕様では、APIの呼び出し、データベースへの問い合わせ、計算処理などがツールの用途として挙げられています。

MCPを採用すれば、必要な業務操作まで自動的に用意されるわけではありません。すべてのMCPツールにAPIが必須というわけでもありませんが、既存の業務機能がAPIとして整理されていれば、それをMCP経由で使う道も作りやすくなります。

接続方式やAIの道具が変わっても、注文を取得する、在庫を確認する、変更を反映するといった仕事は残ります。だからこそ、操作の中身を特定の画面に閉じ込めず、再利用できる形にしておくことが、次の開発にも効いてきます。

返事を書くところから、処理を終えるところまで

冒頭の商品交換に戻ってみます。AIに任せたいのは、「交換の手順はこちらです」と答えるところまででしょうか。それとも、交換に必要な処理を進めるところまででしょうか。この違いで、用意するものは大きく変わります。

まず、対象の注文、購入した商品、発送状況を確認する。次に交換条件と在庫を調べ、どの処理が必要かを組み立てる。担当者がその内容を確認して承認したら、システムに変更を反映し、結果を確認して対応履歴を残す。こうして初めて、依頼への対応が一区切りつきます。

この流れで重要なのは、APIが「あるか」だけではなく、任せたい仕事に必要な操作がそろっているかです。注文を読むAPIがあっても、交換の登録ができなければ、その工程は人に残ります。顧客向けの情報取得ができても、担当者に必要な変更権限まで扱えるとは限りません。

AIにツールを与えるFunction callingは、モデルを外部のデータや処理につなぐ仕組みです。OpenAIの公式ドキュメントが説明するように、モデルが必要なツールの呼び出しを要求し、アプリケーション側が実行して、その結果をモデルに返します。

画面を直接操作する方法も選択肢になります。ただ、繰り返す業務であれば、何を渡し、何が返り、どこまで実行できるかを明示できるAPIから検討したいところです。実行前に人間が内容を確認し、途中で止められる境界も設計します。MCP Toolsの仕様も、アクセス制御や重要操作の確認、監査のためのログを扱っています。

答えの文章がもっともらしいことと、システム上で処理が完了していることは別です。APIは、AIの提案を実行につなぎ、その結果を確かめるための接点でもあります。

トートバッグの持ち手が変わった日を残しておく

操作の経路を用意すると、次に気になるのは、AIが何を根拠にその操作を選ぶのかです。注文を更新できても、どの条件で交換を受け付けるのか、例外は誰が判断するのかが分からなければ、仕事は進められません。APIという「手」と一緒に、仕事を理解するための「地図」も必要になります。

その地図には、整ったマニュアルだけでなく、日々の小さな変更も含まれます。たとえば、トートバッグやショルダーバッグなど、複数の商品をECで販売している会社を想像してみてください。ある日、定番トートバッグの持ち手の長さを12cmから16cmへ変更したとします。

商品マスターを更新すれば、現在の長さは分かります。しかし、それだけでは、以前の注文がどちらの仕様だったのか、いつから変わったのか、なぜ変更したのかまでは分かりません。古い仕様の商品を買った顧客から問い合わせが来たとき、最新の商品情報だけを見て答えると、話が食い違うかもしれません。

理想は、商品マスターの更新と同時に、変更理由や適用時期、承認の記録を結び付けることです。そこまで仕組みが整っていなくても、まず「どの商品が、いつ、どう変わったか」を残すことはできます。担当者や元の資料も一緒に記録すれば、後から確認する足がかりになります。

さらに、商品情報や売上推移をAPIで取得できれば、その記録と並べて調べることも考えられます。変更後に売上が伸びていたなら、仕様変更との関係を検討するきっかけになるでしょう。ただし、同じ時期に広告を増やしたのか、価格を変えたのかでも解釈は変わります。時期が重なっただけで、持ち手を伸ばしたことが原因だとは言えません。

大切なのは、AIが後から考えるための材料を失わないことです。現在の正しい値を持つことと、そこに至る出来事を残すことには、それぞれ違う役割があります。

Memosのように、まず短い記録を積み重ねる

こうした記録を、毎回きれいな報告書にする必要はありません。Memosは、短いノートやログ、アイデアを時系列でたどれるメモの道具です。何かが起きたとき、まず短く書き留める。その小さな記録がタイムラインに積み重なり、後から仕事の流れを振り返る手がかりになります。

先ほどのECの例なら、こんな記録から始められます。

9月1日：定番トートバッグAの持ち手を12cmから16cmに変更することを決定。持ちにくいという声への対応。商品企画の担当者が確認。9月10日出荷分から適用予定。仕様書へのリンクを添付。

これは架空のメモですが、単に「持ち手を変更」とだけ書く場合との違いは見えると思います。商品が特定でき、理由があり、決定した日と適用する予定日を区別できる。9月10日に予定どおり切り替わったなら、その結果をもう一つの記録として追加できます。

短いメモのよさは、記録のために仕事を大きく止めずに済むことです。会議の決定、顧客からの声、実施した変更を、その都度残す。後から商品名や日付を手がかりに関連する資料へたどれれば、担当者の記憶だけに頼る状態を減らせます。

もちろん、書き留めた内容がそのまま確定情報になるわけではありません。検討中の案、承認済みの決定、実際に行った変更は区別しておきたいところです。AIが参照するときにも、何が事実で、何が予定だったのかを見分ける材料になります。

たとえば、こうした自然言語のメモをAIにたどらせ、APIで取得した商品情報や売上推移と照合して、仕様変更の前後に何があったかをまとめさせてみる。最初からすべての情報を決まった項目に整理しなくても、短いログを材料に、仕事に使えるかを試すところから始められます。元の記録と照らして結果を確かめれば、商品を特定できない、適用日を取り違えるといった不足が見え、どの情報を結び付けるべきかも具体的になります。

ここでの目的は、最初から一つの完璧なデータベースを作ることではありません。まず元の記録を残し、使いながら、商品情報との結び付けや検索の仕方を整えていくことです。必要な整理の方法が変わっても、元の記録があれば見直せます。記録そのものを残す仕事と、使いやすく加工する仕事を分けて考えると、始め方が少し軽くなります。

まず一つの仕事を通してみる

APIも業務情報も大切だと分かると、すべてを整えてからAIを使いたくなるかもしれません。ただ、何に使うかが曖昧なままでは、どの操作をAPIにし、どの情報を結び付けるべきかも決めにくいはずです。

まずは商品交換のように、一つの業務を選んでみる。情報を取得し、対応案を作り、人間の承認を経て実行し、履歴を残す。その一連の流れを、限定した範囲で通せるかを確かめます。必要な操作が呼び出せないならAPIを整え、古い仕様を判別できないなら変更履歴を結び付ける。止まった場所から、整備の優先順位が見えてきます。

同時に、正しく対応できたか、人の手がどれだけ残ったか、一件にかかった時間と利用コストを測ります。最初は時間や費用がかかっても、価値が確かめられれば、改善後に何を維持すべきかが分かります。検索を絞って速くした結果、必要な記録を見落とすようになったのなら、その改善は見直せます。

データ構造や検索方法には、実際の仕事を見てから決めたほうがよい部分があります。一方で、必要な操作を外から呼び出せること、判断の根拠と結果をたどれることは、どのAIを使う場合にも土台になります。

次に社内システムの開発を考えるときは、画面の向こうに座る人だけでなく、その仕事を引き継ぐAIも思い描いてみてください。任せたい操作を呼び出すAPIはあるか。その操作を選ぶための情報は残っているか。

人間の画面操作を前提に作ってきた社内システムを、AIにも仕事を引き渡せるものへ変えていく。社内システムのAPIを整える意味は、そこにあります。

本稿は@theaktkyと、キジトラの池田の対話を元に内容を再構成したものです。