いいねしたあの投稿、結局読み返してないですよね ども！龍ちゃんです。最近、技術の話って Web じゃなくて X に集まってきてませんか。僕はけっこうそう感じていて、しかも「あとで読もう」と思ったやつほど流れていくんですよね。 最近読んだ中で印象に残っているのが、 @HayattiQ さんのこの投稿 です。AI に「X の今」を調べさせると途端に精度が落ちるのは、AI の能力ではなく情報源の性質の問題だ、という指摘で。 この投稿自体が「X の中にしかない知見」の実例になっている のが面白いんですよね。 正直に言うと、僕もいいねだけして溜め込んでいるクチです。あとで読み返すつもりではいるんですが、実際にコピペして手元に持ってくるのは気が向いたときだけ。数えてみたら月1本くらいでした。 そこで、X API を正規に契約して、Claude Code から叩ける CLI と skill を作りました。いまは記事を読んでいて「これ取っておいて」と言えば、本文が手元に落ちてくるようになっています。 今日話すのはこの4つです。 何をやったらダメなのか 許された道はいくらか 実際にどう作ったか で、何が変わったか 順番に見ていきますね。 そもそも、何をやったらダメなんだろう 「X の投稿を機械で集める」って調べると、無料の抜け道と有料の正規ルートが混ざって出てくるんですよね。ここを先に整理しておかないと、値段の話にも進めないので、きちんと公式に行って「何がダメなのか」を確定させます。ダメには2つの層があります。 機械には、はっきり「来るな」と書いてある 機械で触る前に、まず見にいくのが x.com/robots.txt です。これはクローラー向けに「何を取っていいか」を宣言するためのファイルで、ブラウザで開けば誰でも読めます。 中身はこうでした（2026-09-10 取得）。 User-agent: * Disallow: / User-agent: * はすべてのクローラが対象で、 Disallow: / はサイト全体を禁止する、という意味なんですよね。そのうえで、名指しで許可されているクローラが3つだけあります。Googlebot、Bingbot、facebookexternalhit です。それ以外は、この一行だけで門前払いということになります。 しかも Google-Extended など AI 向けのクローラ7つは、個別に名指しで拒否されています。検索エンジンには来ていいと言いながら、AI には来るなと言っている形なんですよね。 robots.txt はあくまで宣言で、鍵ではありません。でも、X が誰に来てほしくて誰に来てほしくないかは、これで十分伝わってきました。この宣言をどう受け止めるかは、次の規約の話に譲りますね。 規約が、公式 API 以外の自動収集を禁じている 出典は X Developer Guidelines （2026-09-10 取得）です。禁止行為の表に、こう並んでいます。 Non-API Automation: Browser scripting, scraping, any automation outside official API 公式 API を通らない自動アクセスは全部そこに入っていて、ブラウザ操作もスクレイピングも名指しです。帰結も同じページにはっきり書いてあります。 Non-API automation (scraping, browser automation) results in permanent suspension. つまり、アカウントの永久停止です。 正直、非公式のツールやライブラリは実際に動くんですよね。動いてしまいます。でも、動くこととやっていいことは別の話で。 これ、AI 固有の規制ではないんですよね。「AI に取らせるのがダメ」ではなく「公式 API を通らない自動収集がダメ」という話で、人が書いたスクリプトでも同じ扱いになります。どのツールが白でどれが黒かの品評はしませんし、禁止されているのは X 上のコンテンツ （投稿やプロフィール）を機械で集めることであって、開発者向けドキュメントを読みにいくことは別の話です。 もう一つ、取ったあとの話も同じ規約の隣にあります。 Developer Policy は、X のコンテンツをオフラインに保存するなら X 上の状態に合わせて更新し続けること、削除や変更があれば24時間以内に追従することを求めています。本文も画像も同じ扱いです。つまり正規ルートで取ること自体は問題なくても、 手元に溜めた瞬間に「X で消えたら消す」義務が付いてきます 。今回は本文は手元に置いているので、この義務を引き受けている側です。月に数件なので手で追えますが、溜め込む設計にするなら削除に追従する仕組みまで要る、ということは先に知っておいたほうがいいです。 なお、ここで扱うのは「取る」話だけです。出す（投稿する）側の自動化は AIチャットで話すだけ!X予約投稿を完全自動化するシステム構築術 に書きました。 じゃあ、許された道はいくらなんだろう 「X の投稿は取れない」わけじゃないんですよね。正確には「タダでは取れない」です。公式にお金を払ってAPIを使おうねって話です。 入口は2つある。どちらも同じ財布に乗る 許された道は2つあります。ひとつは公式 API を自分で叩くこと、もうひとつは公式の MCP サーバ（xmcp）を繋ぐことです。MCP を繋ぐと、AI が自分でその場から API を叩けるようになります。ただ、xmcp を繋いでも請求は結局こちらの API プランに乗ります。少なくとも僕が調べた範囲では、MCP 経由なら無料になるという枠は見つかりませんでした。繋ぎ方は公式が X MCP Server にまとめてくれているので、ここでは同じ財布に乗るということだけ触れておきます。 無料枠はもう消えていて、読み取りは1リソース $0.005 X API の料金ページ を開くと、載っているのは従量課金の説明だけで、無料で使える枠の案内はどこにも見当たりません。以前は無料枠があったので、「まずは無料で試してみましょう」と書いてある記事はもう前提が違うんですよね。読み取りは $0.005 / リソースと書いてあります。 で、実際どうやって取るの 先に済ませておくことが2つあります やることは2つで、 認証情報を1つ発行すること と、 クレジットを買っておくこと です。 ひとつ目。開発者アカウントを作ってアプリを作ると、認証情報がいくつか発行されます。API Key、API Secret、Access Token……と並ぶので身構えるんですが、 投稿を読むだけなら Bearer Token 1つで足ります 。残りはユーザーの代理で動くとき（投稿する側）に使うものです。手順は公式の Getting Access が3ステップで書いてくれています。 ふたつ目。 クレジットを先に買っておきます。 X API には無料枠が無いので、アカウントとトークンを揃えても、クレジットが入っていなければ何も取れません。Getting Access の次のページは、もう「最初のリクエストを送ろう」です。 ちなみに僕が買ったときは、クレジットの最低チャージ金額が「$5」でした。日本円だと760円ぐらいですね（2026-09-10 時点）。 「円安やべ〜」とは思いました。でも、必要なコストだと割り切ってAPIのクレジットを買っておきましょう。1件 $0.005 なので、1件だけのつもりで払っても1000件ぶんが残る計算になります。 公式 MCP があるのに、自前で CLI を作りました 理由は2つあります。 ひとつは、やりたいことがすごく狭かったこと。記事を読んでいて X のリンクを見つけたときに、本文を全文コピペするんじゃなくて、URL を渡したら手元に落ちてくる。欲しかったのはそれだけなんですよね。X に対して何でもできる口を開けておく理由がありませんでした。 もうひとつは、従量課金を AI に自由に叩かせたくなかったこと。怖かったのは、リクエスト単位で請求が立つことです。叩いた瞬間に金が減ります。それに、もし自動でクレジットが補給される設定になっていたら、残高が切れても止まらないんじゃないか、とも思いました。ここは仕様を確認していません。確認していないので、最悪のほうに倒して設計することにしました。止まらない前提で組んでおけば、実際に止まる仕様だったとしても損はしないので。 もう少し言うと、MCP は道具が束で載っている形なんですよね。繋いだ瞬間に使える口がいくつも開いて、そのどれをどう使うかは、その場のプロンプト次第になります。 使ってほしくない使い方を止めたければ、お願いするしかない。 自前の CLI にすると、そこが変わります。縛るのが言葉じゃなくて 機能の形 になるので、たとえばまとめ取りは「やらないでね」ではなく「 そもそもできない 」になるんです。 公式の MCP（xmcp）を繋いでも、叩く前に確認を挟むこと自体はできます。Claude Code は MCP 経由のツール呼び出しにもちゃんと確認ダイアログを出してくれるので、そこは正直に認めておきたいです。ただ、あのダイアログが聞いてくれるのは「叩いていいか」だけなんですよね。 実行そのものは CLI 側に制約として持たせて、すでに取得済みの投稿かどうかの確認は skill に手順として持たせています。人間がやることとしては、X のリンクを共有するだけですね。 Step 0: 叩く前に、すでに取得済みかを確認する（同じ投稿を二度取らない） Step 1: 2件以上は件数と概算費用を先に申告して合意を取る まとめて取る機能をあえて作っていないのも同じ理由です。金が減る操作は狭いところから始めるほうが安全で、狭くて困ったら後から足せても、広くしてから事故ると戻せないからです。 叩いてみると、レスポンスで2回つまずきます 僕は自作の CLI から叩いていますが、やっていることはこの curl 1本と変わらないので、そのまま打てる形で書きます。 curl -H "Authorization: Bearer $BEARER_TOKEN" \ "https://api.x.com/2/tweets/<post_id>?tweet.fields=article,created_at,public_metrics&expansions=author_id,article.cover_media,article.media_entities&media.fields=url" 先に1つだけ。 返ってきた生の JSON は必ずファイルに残してください。 叩いた時点でもう金は減っているので、捨てると同じ金を払って取り直すことになります。僕はレスポンスとヘッダーの原本を _raw/ に、消費クレジットの台帳を1行1件で残すようにしました。 ここからが本題です。いちばん時間を溶かしたのがレスポンスの読み方でした。素直に叩くと、 text には23字しか入っていなくて焦ります。本文は article.plain_text のほうに全文入っていて、実測で1,647字ありました。冒頭の抜粋じゃなくて末尾まで、です。 しかもこの article は、リクエストで tweet.fields=article を明示しないとそもそも返ってきません。指定せずに GET /2/tweets/<id> を叩くと、返ってくるのは23字のほうだけです。公式ドキュメントには article のサブフィールドの定義が無いので（2026-09-09時点）、何が返ってくるかはドキュメント側からは埋められず、実測でしか分かりませんでした。 もうひとつ、画像でも踏みました。最初に取ったとき、Article の本文中の画像は ID のまま残って、実体で返ってきたのはカバー画像1枚だけだったんですよね。原因は僕の指定漏れで、 expansions に article.media_entities を足すだけで、本文中の画像も同じ1回の includes.media に URL 付きで返ってきます。実測だと本文の画像2枚とカバー1枚の計3枚が全部入りました。通常の投稿に添付された画像も同じで、こちらは attachments.media_keys です。どちらも media.fields=url を付けないと media_key と type しか返らないので、そこだけ注意です。 返ってくる URL は pbs.twimg.com のもので、そこから先は認証なしの普通の GET で落ちます。 ?format=jpg&name=orig を付ければ原寸です。 includes 側なので追加の課金は無く、コンソールの累計も投稿ぶんしか動いていませんでした。 ただ、落とした画像ファイルを手元に置くのはやめました。最初に書いた削除追従の義務は画像にも同じに掛かるからです。持たなければ負わないので、URL だけを保存して、中身が要るときに CDN から読んで、読んだら消すようにしています。将来的には、投稿も自分の環境に生かせる内容として取り込んだら消す運用にする予定です。 結局いくら払っているのか、確かめてみる レスポンス自体は消費クレジットを返してくれません。ヘッダーまで全部見ても、課金に関係するのは rate-limit 系だけでした。ここは生ヘッダーごと _raw/ に落としてあるので、後から数え直せます。とにかく、実額はコンソールの残高でしか追えないんですよね。 ここで数え方の話をします。コンソールの残高はセント単位に丸められるので、 1回叩いただけでは単価が出ません 。$0.005 を消費しても、減り方は $0.01 に見えるんですよね。2回叩いて累計 $0.01 まで来て、ようやく料金表の $0.005 と整合します。ただし丸めが残るので、2件で言えるのは「表の値と矛盾しない」まで。幅を潰したいなら10回叩いて $0.05 を見るのが早いです。僕は2回で止めました。 分かったことは2つです。ひとつは、著者やメディアといった関連データ（ includes ）が 課金対象じゃない こと。取得した2件にぶら下がっていた1件と2件は、請求に乗っていませんでした。 もうひとつが、いちばん確かめたかったところで。僕が読みたい Article（長文記事）付きの投稿は、料金表に行が存在しないんですよね。Read 表12行・Write 表16行、全部見ても無い。つまり表を読んだだけじゃ、自分が払う額が分からない。それが叩いてみたら、通常の Post 読み取りと同じ $0.005 でした。拍子抜けではあるんですが、 通常のポストと同じ金額で大量の文章情報が取れるってのはうれしいですね！ ここまでに出てきた金額を、いちど並べておきます。 何に いくら どこで分かるか 投稿1件の読み取り $0.005 料金表の Read の行 Article 付きの投稿 $0.005 叩いて実測（料金表に行が無い） includes （著者・メディア） $0 2件を突き合わせて確認 画像の URL（ includes.media 。添付も Article 本文中も） $0 写真4枚の投稿を2回取って、累計が投稿ぶんしか動かないのを確認 クレジットの最低購入額 $5 から コンソール（料金ページに記載なし） まとめ取りの課金単位 不明 1件ずつしか叩いていない 変わったのは、「あとで読む」が消えたこと 一文で言い切ると、払った金額が何かを変えたわけじゃないんですよね。$0.005 はただの入場料です。変わったのは、自分の環境に繋いだことのほうでした。 いま X の URL を Claude Code に渡すと、「これ取っておいて」で本文が手元に落ちてくるようになっています。最初に挙げた @HayattiQ さんの投稿も、実はこの経路で手元に落ちてきたものだったりします。 正直に計算すると、月1本の作業を自動化するのに CLI と skill を書いたわけで、費用対効果で見るとゴミですね。時間が浮いた、という話でもない。消えたのは「あとでやろう」のほうです。これまでは、X の中にある情報に対して「気が向いたらコピペする」以外の触り方を持っていなかったので、取りにいく発想がそもそも無かった。それが URL を渡すだけになると、 取りにいこうと思えるようになります 。 最初の一歩として渡すのはひとつだけです。CLI を書けとは言いません。まず1件だけ、正規ルートで取ってみてください。表に載っていない自分のユースケースの単価は、そこで初めて見えてきます。 ちなみに正規のルートはもう一本あって、Grok（xAI）から X を検索させる道です。そっちは X API のクレジットとは別の勘定、別の課金体系になります。ただ、値段の付け方が 2026-09-21 に変わるので、そこも含めて 別記事にまとめました 。課金して実際に叩いています！ ではまた！ 付録： article のキーは、公式に定義が無いので実測を置いておきます 本文で触れたとおり、 article のサブフィールドは公式ドキュメントに定義がありません（2026-09-09 時点）。1件ぶんのレスポンスから読み取れたものを並べておきます。字数はその投稿のものです。 キー 中身 article.plain_text 本文の全文（実測 1,647 字） article.preview_text 冒頭の抜粋（実測 111 字） article.title 記事のタイトル（実測 39 字） article.entities 本文中の構造化要素。 コードブロックが code 配列で取れます article.media_entities 本文中のメディアの ID。実体は includes.media 側に入る 指定しても返ってこなかったものも2つあります。 article_title は tweet.fields の enum にありますが返らず、タイトルは article.title のほうに入ります。 note_tweet は280字を超える長文投稿のためのフィールドで、Article とは別機能なので、Article 付きの投稿では使われません。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIにXの投稿を取らせる正規ルート｜規約と従量課金に制限をつけて繋ぐ first appeared on SIOS Tech Lab .

本ブログは、株式会社アドバンスト・メディア様と Amazon Web Services Japan が共同で執筆いたしました。 1. はじめに みなさま、こんにちは。AWS ソリューションアーキテクトの本田・戸塚と、アカウントマネージャーの兼子です。 本ブログでは、 AWS Summit Japan 2026  で展示した、食品調理現場における業務課題を、音声 AI とマネージドエージェント基盤で解決するアーキテクチャをご紹介します。 Amazon Bedrock AgentCore Runtime と Strands Agents SDK による AI エージェント、 AmiVoice による高精度な日本語音声認識、 Amazon DynamoDB や AWS Lambda によるサーバーレスバックエンドを組み合わせ、「手を使わずにレシピを操作できる」ハンズフリーオペレーションを実現しています。 AWS 側ではエージェント設計・クラウドアーキテクチャ・リアルタイム通信の観点から、アドバンスト・メディア社側では音声認識エンジン AmiVoice の技術特性・業界特化チューニング・認識精度向上の観点から、それぞれ解説します。 2. 飲食業界における現場オペレーションの課題 食品調理の現場、特にセントラルキッチン（複数店舗向けの集中調理施設）では、以下の構造的な課題が存在します。 2.1 手が塞がる環境でのデータ入力障壁 調理作業上、両手は鍋・包丁・計量器などで塞がっています。加えて、衛生管理の厳しい調理現場では衛生手袋を着用しながら調理するため、レシピ確認や在庫記録のたびに手袋を外してタブレットを操作する必要があります。セントラルキッチンでは複数ホテル・複数レシピ向けに大量の食材を一括管理する必要があり、在庫記録の重要性がより高い一方で、以下の問題が連鎖的に発生します: 手袋着脱による作業中断と衛生リスクの増大。また、食品安全のために中心温度の測定・記録が義務付けられているが、手作業での記録は漏れやすく、コンプライアンス違反のリスクがある 紙・Excel 依存によりデータがデジタル化されず、経営判断に活用できない 配布されたレシピを調理現場で調整しているが、現場でカスタマイズされ、記録されずに属人化している レシピは調理現場に持ち込まず、バックヤードに置いているため、新人や不慣れなメニューの場合は頻繁にバックヤードと調理場を往復することになり、作業効率の低下を招く 調理工程の進行状況が在庫管理システムと連動しておらず、食材の消費を都度手入力で記録する必要がある。入力が漏れると在庫の把握精度が下がり、食材切れへの対応が遅れる 2.2 音声認識活用のハードル 音声入力は「手が塞がる環境」の自然な解決策ですが、キッチン特有の課題があります。換気扇・鍋の音などの騒音環境、食材名の専門用語（食品業界固有の表現や略称）、そして方言やイントネーションの多様性です。汎用の音声認識エンジンでは認識精度が業務品質に達しないことが多く、業界特化の音声認識技術が求められます。また、騒音やノイズのある環境下で、正確に発話の意図を把握して操作する精度も求められます。 2.3 レシピ一括管理の困難さ これらの課題は、「現場で変更された変更がレシピ側に伝達されないこと」につながります。調理器具の違いや材料不足、その日の気温といった外的要因からしばしばレシピの変更が発生しますが、手袋着脱や両手作業による入力障壁がデータ不在を生み、それが管理者の可視性欠如、ひいては経営判断の根拠不足へと連鎖していきます。本ソリューションは、高精度な音声認識とAI エージェントによる入力障壁の解消とオペレーションの容易さを起点に、アプリの利用を通じてデータを構造化して蓄積することでこの課題を解決します。 2.4 調理工程の分担・シフト管理の非効率 セントラルキッチンでは、複数の調理スタッフが並行して異なる工程を担当します。しかし担当者の割り当てやシフトの組み合わせは現状では管理者が手動で判断・調整しており、以下の問題が生じやすい状況です: 各スタッフの習熟レベルや当日の人員状況を考慮した工程分担の最適化が属人化しており、担当管理者の経験と勘に依存している 突発的な欠員や工程の遅れが発生した場合の再割り当て判断に時間がかかり、他工程への連鎖遅延が発生する 調理実績データ（誰がどの工程に何分かけたか）が記録されないため、シフト最適化のための根拠データが蓄積されない 3. ソリューション概要 本ソリューションは、ハンズフリーで操作できるレシピ管理ソリューションです。調理者が音声だけで指示した内容を汲み取り、レシピ工程を進め、AIエージェントが次の工程へのナビゲーションや原材料チェック、工程メモといった操作を判断します。 AmiVoice が調理スタッフの発話を高精度にテキスト化し、AI エージェント（Amazon Bedrock AgentCore + Strands Agents）が意図を解釈して、レシピナビゲーション・在庫減算・履歴記録を自律的に実行します。調理スタッフは「ちょっと楽になった」と感じるだけですが、裏側では構造化データが自動的に蓄積され、管理者のリアルタイム可視化と意思決定を支援します。 3.1 主要機能 レシピ操作機能 音声レシピナビゲーション — 「次へ」「戻る」で工程を進め、工程完了時に使用食材の在庫を自動減算 AI 代替食材提案 — 「玉ねぎがない」と伝えると、レシピ文脈と在庫を踏まえた代替案を提示 原材料チェック — 「原材料チェック、玉ねぎ300グラム」で食材を照合。玉ねぎ/タマネギ/オニオンといった発話の表記ゆれも吸収 調理タイマー — 音声で開始・停止・リセット 工程メモ — 音声でレシピ工程にメモを追加し、ナレッジの蓄積に繋げる 図1 : 個別レシピ画面 レシピの変換機能 現状、Excelで管理しているレシピから、システム管理できる形式への変換 紙管理しているレシピを読み取り、システムで管理できる形に変換 図2 : レシピ取り込み画面 ダッシュボード機能 調理工程ごとの時間をアプリ側で測っておき、ダッシュボード上で可視化 図3 : ダッシュボード画面 アプリケーションは以下のように動作します。 4. システムアーキテクチャ 4.1 全体構成 図4 : システムアーキテクチャ システムは以下の 3 層で構成されています。 層 担当 主要技術 通信プロトコル プレゼンテーション層 ブラウザ画面・音声UI・BLE連携 Amazon S3 + Amazon CloudFront + AmiVoice API HTTPS / WebSocket / Web Bluetooth AI 判断層 音声コマンド解釈・ツール選択・応答生成 Bedrock AgentCore Runtime + Claude Sonnet 4 WebSocket (双方向ストリーミング) データ層 レシピ・在庫・履歴・チェック記録 Amazon DynamoDB + AWS Lambda + API Gateway HTTPS REST アーキテクチャはAI Agent基盤をはじめ、フルサーバレス構成を採用しています。そのため、インフラストラクチャの管理をAWSにオフロードすることができ、運用負荷を抑えつつ、使われていない時間帯のコストも低く抑えながら利用できます。 AI エージェントを通さない単純な読み取り操作は Amazon API Gateway から AWS Lambda を介して処理し、レイテンシを数百ミリ秒に抑えています。一方、音声を通じた操作は、 AmiVoice API を介して発話内容をテキストに起こしたのち、Amazon Bedrock AgentCore で処理しています。なお、ビジネスロジックは同等の Lambda 関数を呼ぶことで、同じロジックを複数の入口から再利用しています。 4.2 AWS リソース構成 全リソースは AWS CDK で定義しています。 カテゴリ リソース 用途 AI エージェント Bedrock AgentCore Runtime (Docker/Python) Strands Agent + Bedrock Claude Sonnet 4 コンピュート AWS Lambda (Python 3.12, ARM64) ビジネスロジックを実行 データベース Amazon DynamoDB Recipes / Inventory / History / IngredientChecks といったデータを保存 API Amazon API Gateway REST API Cognito Authorizer 付きデータ読み取りエンドポイント 認証 Amazon Cognito User Pool + Managed Login OAuth2 PKCE フロー、JWT 発行 CDN Amazon CloudFront, Amazon S3 SPA配信 + AgentCore リバースプロキシ + 画像CDN シークレット AWS Secrets Manager AmiVoice 認証情報を格納 IaC 補助 CloudFront Function SPA フォールバック + AgentCore パス書き換え 音声合成 Amazon Polly レシピ工程の読み上げ音声生成 4.3 AI エージェント設計 本システムの核となる AI エージェントは、Amazon Bedrock AgentCore Runtime 上で動作する Strands Agentsで実装しています。 エージェントは、中央のオーケストレーターがいて、ツールを @tool デコレータ でラップし、必要に応じて呼ぶ構造です。プログラマが分岐を記載するのではなく、判断そのものを LLM に任せるのが従来との大きな違いです。@tool は Strands SDK のデコレータで、関数の引数名・型とdocstringが自動的に LLM 向けの「ツール仕様」に変換されます。したがって、docstring は人間が読む際のコメントであると同時に、LLM が呼び方を理解するための仕様書にもなります。 ■ ツール定義 ツール名 役割 get_recipes レシピ一覧取得 get_recipe レシピ詳細取得 update_step_memo 工程メモ更新 get_inventory 在庫一覧取得 get_inventory_item 食材単品在庫取得 deduct_inventory 在庫減算（工程完了時） rollback_inventory 在庫ロールバック（戻る時） record_history 調理履歴記録 get_history 調理履歴取得 check_ingredient 原材料チェック照合 record_step_time 工程実績時間の記録 clear_ingredient_checks セッション配下の原材料チェックを全削除 invalidate_step_time 「戻る」時に工程の実時間記録を無効化 answer_recipe_question 調理に関する質問をナレッジベースから検索して返答 ■ プロンプト設計 システムプロンプトはハイブリッド方式を採用しています: 指示文（条件分岐、制約、スキーマ定義）: 英語で記載。トークン効率が高い コマンド例、出力メッセージ、食材名 : 日本語。ユーザー体験を優先 message フィールドは必ず日本語で出力するよう明示的に制約 この設計により、日本語のみのプロンプトと比較して入力トークン削減を実現しつつ、日本語での自然な応答品質を維持しています。 ■ 音声認識から画面操作までのフロー 図5:音声の発話からAI Agentが動作するイメージ 発話した内容をもとにページ操作を行うまでのフローは、下記の通りです。 音声入力 マイクまたはテキスト入力で文字列を受け取ります。 コンテキストの付与 発話テキストだけ送っても、LLMは「今どのレシピの何工程目か」という情報を知りません。そのため、コンテキストとしてページの位置情報、工程の調理内容や使用する食材も送付しています。このような構成にすることで、ユーザーが「省略した言葉」を補うことができます。人間同士の会話で「次」と言えば通じるのは、お互いが状況を共有しているからです。LLMにも同じ状況を渡すことで、人間相手のように省略して発話しても操作することができます。また、騒音で音声認識が乱れてユーザーの発話を正確に書き起こしできない場合でも、表記ゆれや誤変換を吸収してLLMが意図を汲んで操作することができます。 LLMが遷移先を判断 システムプロンプトのルールに従い、context を見て遷移先を決定します。JSON形式で返答します。 { "action": "navigate", "page": "recipe", "params": { "recipeId": "recipe-001", "stepNumber": 4 } } しばしばLLMの出力をアプリケーションで扱うとき、プロンプトで「JSON形式で出力して」と指示しても、余分な説明文が付加されていたり、フォーマットが微妙に崩れていたりと出力がぶれることがあります。そこで、Amazon Bedrock の Structured outputs を利用して一貫性のあるJSON出力に強制しています。Structured outputs は、必要な形式を事前に指定してそれに一致するレスポンスを受け取ることができる機能です。 フロントエンド側でページを遷移 フロントエンド側のコードで、返ってきたJSONの action を見て処理を振り分けます。対応するページコンポーネントの再描画や、ページ遷移を実施します。 4.4 AI エージェント設計アプリケーションへの AmiVoice の組み込み 音声の認識には、アドバンスト・メディア社の提供する AmiVoice を採用しています。 マイクの起動 音声認識特化型Bluetoothマイク AmiVoice Front WT01 を介してマイクを起動します。AmiVoice Front WT01は物理ボタン付きのデバイスで、ボタンを押すと Web Bluetooth API を介してブラウザ上のアプリケーションに接続します。Web Bluetooth APIはブラウザからBluetooth機器に接続する仕組みです。 発話内容の読み取りと発話区間の自動検出 AmiVoice APIを利用して発話した内容をテキスト化します。AmiVoice APIには同期・非同期 HTTP と、WebSocket インタフェースがありますが、WebSocketインタフェースを利用して中間認識結果をリアルタイムで表示しています。ユーザーの体感速度を大きく左右する要因です。 また、音声の中で発話区間を自動検出しているため、話し終えたタイミングでボタンを押すことなく発話の終了を検知しています。AmiVoiceの発話検出では深層学習モデルを使って、 人の声とそれ以外を区別していることが特徴 です。 最終的に、テキスト化されたコマンドを Amazon Bedrock AgentCore に送信します。 5. 音声認識エンジン: AmiVoice の技術 (1) AmiVoice の技術的特徴 音声認識には、音声から特徴量を抽出する音響分析と、特徴量を入力として認識結果のテキストを得る認識デコーダの二つのステップがあります。様々な周波数で構成されている波形データを音響分析で音の特徴に数値化して、その特徴量を認識デコーダに入力しています。 AmiVoice APIは、認識デコーダのタイプにより、「DNN-HMMハイブリッド型（以下、ハイブリッド型）」「End-to-End型」の2つのタイプがあります。伝統的な統計モデルである、「発音辞書」「音響モデル」「言語モデル」を組み合わせて音声認識を行うハイブリッド型に対して、End-to-End型は音声入力から直接文字列を出力する一体型の処理という大きな違いがあるのですが、どちらのタイプでもDNNというディープラーニングモデルが使われています。 図6 : ハイブリッド型認識デコーダのイメージ DNN（Deep Neural Network：ディープニューラルネットワーク）は、多層構造を持つニューラルネットワークです。ニューラルネットワークは、生物の神経回路網を計算機上で模した技術であり、音声認識の分野ではDNNを用いた音響モデルが、音声特徴量から音素を推定する仕組みとして従来のGMM-HMMに代わって主流となりました。その後、音声認識技術は、時系列データを扱いやすいLSTMやBiLSTM、さらに広範囲の文脈を効率的に学習できるTransformerへと発展してきました。これらのモデルは構造こそ異なりますが、いずれも音声と発話内容の関係を学習し、入力音声から発話内容を推定するという基本原理は共通しています。 AmiVoice APIは、音声認識技術をシンプルにご利用いただけるAPIサービスです。インターネットからの簡単な登録だけで、すぐに利用を開始できるため、音声認識機能を手軽かつスピーディーにアプリケーションやサービスへ組み込むことができます。日本語に対する高い認識精度を特長とし、ビジネス利用を想定した言語モデルにより誤認識の低減を実現しています。また、医療・金融・保険・コンタクトセンターなどの業界特有の専門用語に強く、製品名や固有名詞の登録にも対応しています。特別な知識や発声の訓練を必要とせず、普段どおりの自然な会話を高精度に認識できます。また、話者による発音の傾向やイントネーションの違いの影響を受けにくく、騒音環境や電話音声でも安定した認識性能を発揮します。国内で開発・運用されているため、音声データを国内環境で安全に管理できる点も大きな特長で、セキュリティを重要視するお客様にも多数選ばれています。 図7 : AmiVoiceの音声認識技術 AmiVoice APIを選んでいただいたお客様に高く評価されているのがリアルタイム性を追求したWebSocket API のストリーミング型音声認識です。AmiVoice APIのWebSocketインタフェースでは、クライアントが開始s・音声送信p・終了eの各コマンドを段階的に送る一方、サーバーは発話開始S、終話E、認識開始C、途中結果U、確定結果Aをイベントとして逐次返します。これにより、音声を最後まで送り切ってから一括変換するのではなく、発話区間ごとに認識を進めながらテキストを即時更新できます。さらに、発話検出で無音と発話を細かく切り分け、resultUpdatedIntervalなどの設定で途中結果の返却タイミングを制御できるため、ユーザー画面には短い間隔で認識文が反映されます。結果として、リアルタイム音声送信に対して遅延のない逐次テキスト化を実現できる点が大きな特長です。 3つの発話区間を検出した場合の、コマンドとイベントのシーケンスは以下のようになります。 図8 : コマンドとイベントのシーケンス (2) 食品製造現場への適用と認識精度の向上 アプリケーションはキッチン等の騒音の多い環境で利用されることが想定されるため、人の声と不要音を分別して認識できる精度が必要不可欠です。AmiVoice APIは、セグメンタ（VAD）により人の発話区間を高精度に検出し、調理場などノイズの多い環境でも不要音の影響を抑制。背景音・機械音・保留音などを認識対象から適切に除外し、必要な音声だけをテキスト化します。さらに利用シーンに応じたパラメータ調整も可能で、現場で使える安定した音声認識を実現します。 AmiVoice APIは、長年にわたって蓄積した音声認識のノウハウをもとに、高精度な言語モデルを構築しています。最新のニュースや業界文書などのテキストコーパスを活用し、新語や業界特有の用語にも迅速に対応します。また、不要データの除去、専門用語の読み登録、表記統一、誤認識分析、パラメータチューニングなどを継続的に実施することで、変化する言語環境に適応しながら高い認識精度を維持します。これにより、食材名・調理用語など業界特化の語彙への対応も可能です。 同じ用語の表記ゆれに対応する際、音声認識だけでなく生成AI（LLM）を活用する方が効果的な場合があります。例えば、品種名である「ヒノヒカリ」を単語登録し、”ひのひかり”の認識精度を上げることは有用と思われます。しかし、”なす”を「茄子」や「ナス」に変換する目的で単語登録すると、意図しない箇所で「茄子」や「ナス」が誤って出現する可能性があります。このような場合の表記ゆれの統一は、単語登録ではなく、文脈を理解できるLLMに任せることで副作用を抑えながら「なす」「茄子」「ナス」を同じ食材として柔軟に扱うことができ、より高い効果が期待できます。 (3) 今後の展望 AmiVoiceは、クラウド環境だけでなく、スマートフォンやタブレット上で動作するオンデバイス型、お客様環境内で音声認識を完結できるオンプレミス型SDKも提供しています*1。音声データを外部へ送信できないセキュリティ要件の厳しい環境や、ネットワーク帯域が限られる現場でも、高精度な音声認識を実現します。利用環境や運用ポリシーに応じて最適な構成を選択できるため、製造、物流、医療、食品業界など幅広い業務シーンにおいて、安心・安全な音声活用による業務効率化を支援します。 今後は、これまで進めてきた業種・業務に特化したSaaSソリューションとの連携・組み込みをさらに拡大し、音声認識技術の活用シーンを広げていきます。加えて、新たな取り組みとして、AIエージェントが業務プロセスの中で音声認識を活用し、自律的に業務を遂行できる次世代ワークフローの実現を目指していきます。 *1 AWSMarketPlaceではクラウド型AmiVoiceAPI(AmiVoiceCloud Platform)のみの提供となっております 6. 他インダストリーへの応用可能性 本ソリューションのコアパターン「音声認識 (AmiVoice) × AI エージェント (Bedrock AgentCore) × 構造化データ自動記録」は、手が塞がる業務環境全般に適用可能です: インダストリー 応用例 期待効果 食品製造全般 外食チェーンのセントラルキッチン、給食センター、食品工場 在庫自動管理、HACCP 準拠記録、熟練者依存の解消 ホテル・宿泊業 ルームメイキング手順ナビ、備品在庫管理、設備点検記録 品質標準化、記録工数削減 医療・介護 手術室での手順確認、投薬チェック、バイタル記録 衛生環境維持しつつ情報アクセス、記録自動化 製造業 組立作業手順ナビ、品質検査記録、設備保全チェック 教育期間短縮、技能伝承のデータ化 物流・倉庫 ピッキング指示、検品記録、入出庫管理 ハンズフリーオペレーション、誤出荷防止 フィットネス・スポーツ トレーニング指示、フォームチェック、セッション記録 指導品質の標準化、データドリブンな改善 技術的な拡張ポイント: Strands Agents のツール定義 (@tool デコレータ) を差し替えるだけで異なるドメインのエージェントを構築可能 AmiVoice の単語登録を実施することで、医療用語・製造用語などの独自の用語にも精度改善が期待できる AgentCore Runtime のマネージド環境でスケーラブルに運用でき、マルチテナント化も容易 7. まとめ 本ブログでは、セントラルキッチンの業務課題を、AmiVoice による高精度音声認識と Amazon Bedrock AgentCore による AI エージェントの組み合わせで解決するアーキテクチャを紹介しました: AmiVoice — 騒音環境・食品業界用語に対応した高精度な日本語音声認識で、現場の「声」を確実にテキスト化 Amazon Bedrock AgentCore Runtime + Strands Agents SDK — マネージド環境で AI エージェントを運用し、WebSocket ストリーミングによるリアルタイム対話を実現 Claude Sonnet 4 の Tool Use — 14 個のツールを自律的に使い分け、曖昧な音声コマンドから適切なアクションを導出 構造化 JSON レスポンス設計 — エージェントとフロントエンドの明確なインターフェース契約により、UI 制御の信頼性を確保 サーバーレス従量課金構成 — DynamoDB On-Demand + Lambda ARM64 + CloudFront でコスト効率を最大化 「手が塞がっている環境でのデータ入力障壁」は、食品製造に限らず多くの業界で共通する課題です。高精度な音声認識と AI エージェントの組み合わせは、この課題に対する有力なソリューションパターンです。本アーキテクチャが、音声 AI エージェントシステムの設計を検討されている方の参考になれば幸いです。 著者について 戸塚 智哉 (Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 本田 光来 (Miku Honda) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行っているソリューション アーキテクトです。サーバーレス領域が得意で、好きな AWS サービスは AWS Lambda です。 兼子 友里朱 (Yuria Kaneko) AWS Japanのアカウントマネージャーです。主にサービス業・SIer業界のエンタープライズ企業をご支援しています。新規案件創出数アジア太平洋地域1位（FY24 第1四半期・上半期）、生成AI案件創出金額日本1位（FY25 第4四半期）。趣味はクラシックバレエで、コンクールでは第2位を受賞しました。薬剤師免許保有。 吉田 明日香 (Asuka Yoshida) 株式会社アドバンスト・メディアのセールスマネージャーです。音声認識サービス「AmiVoice API」の提案・活用支援・協業推進を担当しています。幅広い業界においてお客様の音声データ活用や生成AI活用をご支援しています。 小出 泰久 (Yasuhisa Koide) 株式会社アドバンスト・メディアのエンジニアです。オフィスソリューションや医療機器開発のプロジェクトマネージャーとしての経験を活かし、現場視点での音声認識技術の活用に注力しています。

はじめに こんにちは！2026年7月の1か月間、「CA Tech JOB」に参加した池畑です！ 株式 ...