はじめに
2026年10月8日の「JAWS-UG東京 Strands Deciderハンズオン」のイベントメモです。
ハンズオン手順書が公開されているので、当日口頭でガイドや捕捉された内容があると、これから試してみたい人（私とか…え？）が嬉しいかもと思って、作成しました。手順書に書かれていること（コマンド、画面の操作、結果の数値など）は省いています。
未実施（間に合わなかった…これからやる）での作成なので、誤りなど多々あるかもしれません。お気づきの際には、コメント等いただければ嬉しいです。
パート0：導入と事前準備
Strands Deciderの紹介と、AWSアカウントへのログイン、リージョン（東京）の確認。
実行のポイント
- リージョンは「東京」にする。初めてアカウントを作った人は、初期リージョンがシドニーになっていることがあるので確認する（手順書は「東京に設定」とだけ書いている）。
- 手順書はほぼ完成しているので、おさらいや深掘りは手順書で、という位置づけ。
話されたトピック
- Strands Deciderとは：公式の情報は、ほとんど英語のブログだけ。意思決定モデルで、いくつかの選択肢の中から最適なものを瞬時に選んでくれる、 「すごく柔軟なif文」 と言われることもある。9月中旬から話題のJevを、AWS上でもホストできるようにしたもの、という位置づけ。
パート1：環境構築編（CloudFormationスタックの作成）
ローカルPCではなく、EC2上のVS Codeで作業する（Mac／Windows、個人PC／会社PCの環境の差をなくすため）。公式テンプレートはデプロイでエラーが出るので、「うまくいかない場合は修正版のテンプレートで作成」の手順を使う。
実行のポイント
- 修正版のテンプレートをクリックして別タブで開き、Ctrl+Sで保存する。保存名がデフォルトと違っても問題ない。
- パラメータのUserFullName（手順書には出てこない項目）は、何でもよい。
- 「スタックの作成」で出る2つの選択肢は、上の「新しいリソースを使用 (標準)」を選ぶ。
話されたトピック
-
Strands Deciderの原理（スタック作成の待ち時間に解説）
- 普通のLLMは、次に来る単語を確率順に1つずつ予測して文章を作る。Strands Deciderは、その「次の単語を予測する部分」を外し、代わりに与えられた選択肢を採点する処理を付けたもの。
- ベースはQwen3.5-2Bで、小さく高速。「状況」「質問」「選択肢」を渡すと、選択肢ごとの点数を返す。「これを選ぶ」だけでなく、7点・2点・1点のような採点値が一緒に返る。
- 答え方は3種類。Yes/No、複数の選択肢から選ぶ確率、そして説明しにくい
score。
- レオナさん（Fusic）のZenn記事：モデル構造や学習方法、データまで、数式つきで詳しく書かれている。当日の解説は表面的なもので、裏側を知りたい人はこの記事を読むとよい。
-
「このモデルの良さは速さか」
- 文章を生成する能力はない。これまでの新しいLLMの一つ、という認識は改めた方がよい。
- 使いどころは、大量の分岐処理（ワークフロー）の置き換えや、エージェントに問い合わせを渡す前の分類器（Strands Agentsで解ける問題か、人間にエスカレーションすべき難しい内容かを先に判定する）。
- 「選択肢しか返さないのは不便では」という疑問に対しては、既存の技術の組み合わせではあるが、高速にできることで一気に話題になった、という見方。
- 参加者の意見：「早く返してくれるモデルを無理やり使っていたが、ただ判断してほしいだけのケースがあり、乗り換えるのがワクワクする」。
- 活用例として、JevをStrands Agentsのハーネスに組み込んだり、リンターにしている人もいる。
-
ローカルで動かす利点（Jevとの一番の違いはローカルで使えること、という質問への回答）
- 計算機があるなら、自分の環境で動かす方が速い。エージェントを動かす環境に同居させることもできる。
- Jevは米国のサーバーでホストされており、日本からだと距離の分レイテンシが伸びる。ただし、体感できるほどの差かは不明。リアルタイム性が必要なら、ローカルが向く。
- 企業勤めの立場では、情報が外に出ていかないのが大きな利点（社外のサービスにデータを送るだけで、不安になる）。
- Bedrockに載ると選択肢が増える、という期待も。
パート2：開発環境へアクセス
スタック完成後、VS Codeにログインし、ターミナルでPythonの仮想環境を作り、strands-deciderをインストールする。
実行のポイント
- 左のワークショップの下に、
HANDSON.md、README.md、Pythonファイル4つが並んでいるはず。並んでいない場合は、スタック作成時のRepoUrlの設定ミスの可能性が高い。この環境でgit cloneして補えるかもしれないが、未検証。作り直す方が早い。 - ターミナルで、クリップボードへのアクセスを聞かれたら「許可する」を選ぶと、コマンドをコピー＆ペーストで入れられる。
話されたトピック
特になし。
パート3：Step.1 CLIで動かしてみる
strands-decider askで、同じメッセージに対してchoice（担当チームの選択）、noul（緊急性のYes/No）、score（苛立ちの度合い）を試し、3つをまとめて聞くこともできる。
実行のポイント
特になし（手順書のとおり）。
話されたトピック
- 英語で試すと結果が変わる：参加者から、同じ質問を英語で試したら数値が変わった、という報告があった。今のStrands Deciderは英語の方が合っているのかもしれないが、外部で提供されているJevは日本語もかなり良い。使い分けと、AWS側の今後の進化に期待、という話。
パート4：Step.2 HTTPサーバーとして動かす
serveでHTTPサーバーとして起動し、モデルの読み込みを1回で済ませる。curlでリクエストを送り、JSONの回答を確認する。
実行のポイント
特になし（手順書のとおり）。
話されたトピック
- 出力トークンが1になるのは、文章を作らず1回の計算で答えを出すため。Jevで出力トークンの料金がかからないのも、小さすぎて、いちいち観測するまでもないからだろう、という話者の推測。
パート5：Step.3 Strands Agentに組み込む
Strands AgentsのIntervention（ツールを呼ぶ直前に処理を差し込む仕組み）に、Strands Deciderを組み込む。「天気を教えて」とだけ頼まれたエージェントが、都市を勝手に推測して天気ツールを呼ぶのを、Deciderが止めて聞き返させる。
実行のポイント
- モデルIDの
usをjpに変えるのは、東京リージョンで動かしているから。 - 利用できるなら、手順書のClaude Haiku 4.5の代わりにClaude Haiku 5.5を使ってもよい。ただし、AWSアカウントでの利用許可が必要。新しいモデルは企業のアカウントでないと使えないことが多い。5.5で動いたら、ぜひXで共有してほしい（当日、動いた人を募っていた）。
- 結果の読み方：Deciderは2つの質問をYes/Noで判定している。
-
args_grounded：ツールの引数が、ユーザーが実際に言ったことに基づいているか。0に近い＝根拠がない。 -
premature：ユーザーに確認する前にツールを呼ぶのは早すぎないか。1に近い＝まだ早い。 - 当日は、
args_groundedが0に近く、prematureが0.65で、「まだ答えてはダメ」と判定された。
-
- エージェントが場所を聞き返す理由：サンプルのシステムプロンプトに
immediately（さっさとツールを使って答えなさい）と書いてあるため、普通に動かすと、場所を聞かれていないのに、 適当な都市（例：シアトル） の天気を答えてしまう。
話されたトピック
- Interventionの使いどころ：Claude Codeのフックのように、ツールを使う前に危険なコマンドを弾く、といった用途。ここではその前段にDeciderを置いて、エージェントに処理させるか、人間にエスカレーションするかを振り分ける。
- この判定により、AIエージェントのハルシネーションを防げた、というのが話者の整理。
パート6：Step.4 LLMと人間のルーティング判定
ヘルプデスクのAIエージェントに来た問い合わせを、LLMを呼ぶ前に、AIで答えるか人間の担当者に回すかをDeciderが判定する。5件の問い合わせを順に処理する。
実行のポイント
- 作業ディレクトリは、1つ前のディレクトリ（
workshop）に戻って実行する。
話されたトピック
- 活用のイメージ：LLMと人間でタスクを振り分ける仕組みは、アプリケーションの作り次第で幅が広がる。情シスのような部門が、組み込んだものを用意して提供する形が良さそう。
- 人間に回すケースは、LLMに一切処理が流れない（
llm_input_tokens=0）ので、LLMのコストもかからない。
パート7：Step.5 LLMのルーティング判定
依頼の難しさに応じて、安いモデル（Claude Haiku 4.5）と賢いモデル（Claude Sonnet 4.6）を使い分ける。Strands AgentsのModelRouterの、モデルを決める部分を自作して、Deciderに判定させる。
実行のポイント
特になし（手順書のとおり）。
話されたトピック
-
割り振りの限界と使いどころ
- 今回の例は、簡単な依頼と難しい依頼がはっきり分かれる分かりやすい例。コーディングのタスクの割り振りとなると、もっと難しそう。
- ヘルプデスクのように、「データソースを検索して、見つけたものを返す」だけなら、Haikuで十分。手続きが絡む場合は、Sonnetなど別のモデルを挟む、あるいは人間にそのまま回す、という使い分けもできる。
パート8：Step.6 担当エージェントへのルーティング
Strands Agentsのグラフ（複数のエージェントをつなぐ仕組み）で、エージェント同士をつなぐ線（エッジ）の条件の判定にDeciderを使う。受付のエージェントがチケットにまとめ、Deciderが請求／技術／営業の担当を選ぶ。
実行のポイント
- グラフの理解の助けになる図解：エージェントAにユーザーのリクエストが届き、AがBに渡すかCに渡すかを分岐する。グラフはマルチエージェントのオーケストレーションの機能で、機械的に決める部分と、エージェントが自律的に処理する部分を分けて設定できる。今回の「A→B／C」の分岐の判断に、Deciderを使う。
- コードで見るポイント：
build_graphの中で、add_nodeでエージェント（受付、請求、技術、営業）を登録し、add_edgeで受付から各チームへの線を引いて、conditionで分岐させている。
話されたトピック
- 結果だけ見ると、Step.4（LLMと人間の振り分け）と変わらないように見えるが、決まった定型的な複雑なワークフローや、マルチエージェントのワークフローにも組み込めることを見せる例、という位置づけ。
パート9：Step.7 ツールを実行してよいかを決める
Strands AgentsのHumanInTheLoopで、ツールの実行前に人間の承認が要るかを、Deciderのnoulで判定する。ファイルの一覧や読み取りは自動、メール送信やファイル削除は人間に確認する。
実行のポイント
- 実行すると、ログの出方がごちゃついて分かりにくい。最後に表示される最終結果を見ると、何が実行され、何が拒否されたか（メールは送られ、
tmp/old.logは残った）が分かりやすい。
話されたトピック
- この用途は、必ずしもDeciderを使う必要があるわけではないが、HITL（人間の確認）の仕組みに組み込める一例として紹介した、という話者の位置づけ。
- 人間の承認が必要なツールは人間にエスカレーションするので、エージェントの暴走を防げる。
パート10：質疑・おかたづけ・LT・告知
ハンズオン後の質疑、おかたづけ（スタックの削除）の案内、LT、告知。
実行のポイント
- おかたづけは、EC2が気持ち大きめのサイズなので、費用を抑えたい人は早めにスタックを削除する。また遊びたくなったら、作り直せばすぐ遊べる。
話されたトピック
-
質疑：同じ質問で同じ数値が返るのは、サンプリング処理がないからか
- 確率分布は求めるが、通常のLLMと違い、その分布からランダムに値を選ぶ処理は行わない。代わりに、質問のタイプに応じて、最大確率の選択肢や、確率に基づく期待値で結果を返す。同じモデル、同じ入力、同じ実行条件なら、基本的に同じ数値になる。
- 補足（umitsu）：DeciderやJevのような判断モデルは、トークンを選んで文章を生成するサンプリング処理がなく、判断とその確率そのものを返すのが特徴。
- ふくちの整理：LLMは確率分布を出し、その中からランダムに選んで文章を生成する。Deciderは、その手前の確率を返しているだけなので、確率の計算は常に一緒になる。
-
質疑：Bedrockを呼ぶところでエラーになる：モデルIDを
jpにするところまでは確認済みだった。原因はAnthropicモデルの利用申請（最初のユースケースの登録）が済んでいないことで、後で、実際にモデルの申請の問題だったと分かった。よくある詰まりどころ。 -
LT（umitsu）：Jev as a JudgeをStrands Deciderでやってみた
- JevやDeciderのユースケースの一つに、Strands Agentsなど、LLMの出力をJudge（評価）する使い方がある。LLMアプリのトレースに強いLangfuseに、Jev as a Judgeという提案があり、公式ではOpenAIとJevにしか対応していないが、同じことをDeciderでもできそうなので試した。
- 題材は、ステップ4〜5あたりの天気の例（都市を言わずに指示すると、裏でシアトルが引数に入ってしまう）。最終結果を、ツールの結果に基づいた返事をしているか、といった観点でDeciderにJudgeさせ、そのscoreをトレースに貼り付ける。
- 閾値を決めておき、値より低ければ、品質に問題がありそうなので直す、という使い方ができる。LLMもローカルで動かし、gpt-oss 120bを使った。詳しくは後日、記事にする予定。
- ふくちの感想：評価は難しい領域なので、新しい手法が出てきたのは面白い。
-
告知
- AI Builders Day 2026：12月19日、AWSの麻布台オフィス。Strands Agentsの構築や、フロンティアエージェントの活用などを学べる勉強会・カンファレンス。CFP（Call for Papers）を募集中で、締め切りは約2週間後。
- AWSライトニングトークナイト：来週・再来週に、KDDIの高輪オフィスで開催。普段はJAWS-UG東京でランチタイムLT会を開いており、運営側のメンバーが珍しく登壇する回。運営6人と応募のLT4名が登壇する。配信なしの完全オフライン。connpassから申し込む。
参照資料
作成には、生成AIを使用しています。作成に当たっては、以下を参照しました。