AIBR プレミアム
拓海先生、最近部下から「APIにschema.orgを付けるといい」と聞いたのですが、正直ピンと来ません。要するにうちの業務で何が変わるのでしょうか？
素晴らしい着眼点ですね！大丈夫、難しく考える必要はありませんよ。簡単に言うと、schema.orgのAction注釈を使うとAPIが“機械にとって分かりやすいメニュー表”になるんです。
メニュー表ですか。うちのシステムは職人文化の塊で、APIだってバラバラにある。これって要するに、外部の自動化ツールがうちの機能を勝手に使えるようになるということ？
その通りです。もう少し整理すると要点は三つです。1. APIの機能が“誰にでも分かる形式”で表現される、2. 自動化代理（例: 音声アシスタントやチャットボット）がその表現を読んでタスクを実行できる、3. 認証などの実行に必要な情報も付けられる、ということです。
なるほど。じゃあ検索エンジンだけでなく、うちの受注管理や在庫照会を外部ツールに安全に使わせられる、と。ところで導入コストと利益はどう見ればいいですか？
良い質問です。投資対効果の観点でも三点に整理できます。第一に開発側の文書化コストは下がる、第二に外部サービスやパートナー連携が速くなる、第三に顧客接点の自動化で人的工数を削減できる、です。まずは自社で最も価値のあるAPI一点を選び、そこに注釈を付ける小さな実験から始めるのが現実的ですよ。
具体的には、どんな情報をAPIに書き加えるんですか？うちの現場はセキュリティにうるさいので、勝手にアクセスされるのは困ります。
例えば「この操作は予約を作る」「この操作は在庫を確認する」といった動詞的な説明や、必要なパラメータ名、期待される応答形式、そして認証方式の説明を追加します。著者らは認証の記述もschema.org拡張で扱えると提案しており、安全性と自動化を両立させる設計が可能です。
それだと開発チームが手を動かす時間とセキュリティ設計が鍵ですね。失敗しないための進め方は何かありますか？
段階的に進めるのが安全です。まずはドキュメントと実装を分け、注釈だけ作って自動化ツールで読み取り可能かを検証します。次に認証フローを限定的に公開し、実稼働前にパートナー限定で試験する。最後に運用ルールを決める。これならリスクを小さく回せますよ。
これって要するに、まずは注釈を作って読み取らせる実験をして、問題なければ段階的に本番で使う、ということですね？
その通りです。大丈夫、一緒にやれば必ずできますよ。まずは価値の高い一点に集中して、小さく実験、学んで広げるアプローチを取りましょう。失敗は学習のチャンスですから前向きに行きましょうね。
分かりました。まずは受注登録APIに注釈を付けて、外部の対話システムに注文作成を試させる。うまくいけば人的対応を減らせるし、だめでも被害は小さい。要するに自社の重要なAPI一点を選んで、段階的に自動化を進めるということですね。
