はじめに この記事では「IOWNの名前は知ってるけど、実際にどんなビジネスに使えるの？」という疑問にお答えするため、IOWNの特徴を活かしたB2B向けユースケースをご紹介します。 IOWNの特徴 IOWN（アイオン: Innovative Optical and Wireless Network）の概要と特徴についてはこちらのサイトをご参照ください。 https://www.nttdata.com/jp/ja/trends/data-insight/2025/0403/ IOWNは、単に通信経路を光に置き換える技術ではありません。光の強みである大容量・低遅延・低消費電力を通信から

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 めっきり日が短くなり、気づけば今年も残すところ 2 か月あまりとなりました。今週は Amazon Bedrock 上の Claude モデルでの Structured Outputs 対応や、Amazon Connect の脅威検出、AWS Trainium 向けネイティブ PyTorch「TorchNeuron」のベータなど、開発・運用の現場をじわりと支えるアップデートが揃いました。そして年末といえば、いよいよ 11/30（月）〜 12/4（金） に米国ラスベガスで AWS 最大のカンファレンス AWS re:Invent 2026 が開催されます。新サービスがステージで発表され、その日のうちにライブデモや技術セッションで深掘りできる 1 年で最もアツい 5 日間です。現地参加はもちろん、基調講演はオンラインでも視聴できますので、ぜひ予定に入れておいてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月19日週の主要なアップデート 10/19(月) Amazon GuardDuty が Runtime Monitoring 向けのオプション脅威検出ルールを追加 Amazon GuardDuty の Runtime Monitoring に、オプトインで有効化できる脅威検出ルール (Custom Detection Rules) が追加されました。sudoers ファイルの変更や監査ログの無効化のように、ある環境では正常でも別の環境では侵害の兆候となるプロセス・ファイル・ネットワークアクティビティを、環境ごとに選択して検出できます。ルールは AWS が構築・保守するプリビルトで 55 個あり、MITRE ATT&CK のタクティクスに対応した 13 の finding types を生成します。dry-run mode で検出量を事前評価してから live mode に切り替えられます。すべての AWS 商用リージョンと AWS GovCloud (US) リージョンで利用できます。 EC2 Image Builder が ASG と統合しイメージビルドを高速化 EC2 Image Builder が、Auto Scaling Group (ASG) で稼働中の既存 EC2 インスタンスをビルドに使用できるようになりました。従来はビルドのたびに新規インスタンスの起動と初期化を待つ必要がありましたが、この時間を省略できます。インフラストラクチャ設定で ASG を指定すると、Image Builder はその ASG から稼働中のインスタンスを 1 台取り出してビルドコンポーネントを適用し、イメージを作成します。ASG は希望容量の維持によりインスタンスを自動補充するため、次回以降のパイプライン実行にもインスタンスを利用できます。本機能はオプトイン方式で、既存パイプラインへの影響はなく、全リージョンで追加料金なしで利用できます。 Amazon CloudWatch Omni が追加の AWS リージョンで利用可能に Amazon CloudWatch Omni が新たに 8 リージョンに拡大し、東京リージョンを含む合計 11 リージョンで利用できるようになりました。CloudWatch Omni は AWS マネジメントコンソールの外 (SSO 対応の専用 Web UI または IDE 拡張) で提供される AI を活用した可観測性のためのインターフェースで、アプリケーションと AI エージェントのテレメトリを 1 か所で確認できます。OpenTelemetry を基盤とし、既存の CloudWatch テレメトリは再設定なしでそのまま表示されます。今回の拡大により、日本の組織は東京リージョンにスペースを作成し、IAM Identity Center と組み合わせた SSO 構成をリージョン内で完結できます。 10/20(火) AWS IAM Identity Center が Active Directory からのアイデンティティソース変更を簡素化 AWS IAM Identity Center は、アイデンティティソースを Active Directory から外部 IdP (Okta、Microsoft Entra ID など) または Identity Center ディレクトリに変更する際、ユーザー、グループ、グループメンバーシップ、許可セット割り当て、アプリケーション割り当てを保持するようになりました。従来はこの変更で全データが削除され、再作成が必要でした。既存の identity store が維持されるため、ユーザー ID・グループ ID・Identity Store ID は変わらず、これらの ID を参照するポリシーも引き続き動作します。本機能は組織インスタンスを対象に、IAM Identity Center が利用可能な全リージョンで追加料金なしで利用できます。なお、逆方向 (Active Directory への変更) は従来どおり全データが削除されます。 Amazon Bedrock Guardrails が contextual grounding checks の Standard tier をサポート Amazon Bedrock Guardrails のハルシネーション検出機能である contextual grounding checks に Standard tier が追加されました。従来の Classic tier は要約・言い換え・質問応答向けの厳密なグラウンディング評価のみに対応していましたが、Standard tier では推論過程や会話調の内容を含む応答も評価できます。対応言語は英語・フランス語・スペイン語の 3 言語から日本語を含む 80 以上の言語に拡大され、日本語は「最適化およびサポート済み」の位置付けです。料金は Classic tier と同じ 1,000 テキストユニットあたり 0.10 USD です。利用にはガードレールプロファイルによる cross-Region inference の有効化が必要で、東京リージョンを含む 11 リージョンで利用できます。 AWS Clean Rooms が Databricks をデータソースとしてサポート AWS Clean Rooms が Databricks をデータソースとしてサポートしました。コラボレーションのメンバーは、Delta Sharing で共有された Databricks のテーブルを、S3 へエクスポートや複製をせずにコラボレーション内で直接クエリできます。これまで Databricks にデータを持つメンバーは S3 へのエクスポートパイプラインの構築と、コピーされたデータの追加のガバナンスが必要でした。認証には IAM のアウトバウンド ID フェデレーションによる JWT 交換を使うため、長期シークレットの保管は不要です。サポートされるデータソースは AWS Glue (S3)、Amazon Athena、Snowflake に Databricks が加わり 4 種類になりました。 Amazon Bedrock 上の Claude モデルで Structured Outputs が利用可能に Amazon Bedrock が、Anthropic Claude の全モデルで Structured Outputs を一般提供しました。ユーザーが定義した JSON Schema に必ず準拠した JSON レスポンスを受け取れるため、独自のパース処理、リトライロジック、事後検証コードが不要になります。bedrock-runtime エンドポイント (Converse API / InvokeModel API) と bedrock-mantle エンドポイント (Anthropic Messages API) の両方に対応します。レスポンス全体を構造化する「JSON Schema output format」と、ツール呼び出しの入力を検証する「strict tool use」の 2 つの機構があり、併用もできます。Claude モデルが利用可能なすべてのリージョンで使えます。 10/21(水) AWS Transform が新規ネットワークの構築とセキュリティグループの最新化に対応 AWS Transform for migrations のネットワーク移行機能が拡張され、ネットワークを AWS に持ち込む方法が 3 つになりました。従来の「ソースネットワークを新規 VPC にマッピングする移行」に加え、ソース設定ファイルを使わずにゼロから AWS ベストプラクティスに沿った新規ネットワークを設計・構築する方式と、オンプレミスのファイアウォールルールをセキュリティグループに変換して既存 VPC へデプロイする方式を選択できます。セキュリティグループ変換では、実トラフィックデータに基づく未使用ルールの検出や、CIDR ベースのルールからセキュリティグループ参照への変換などの最新化を行います。AWS Transform 自体の利用は無料で、すべての AWS 商用リージョンおよび GovCloud リージョンへの移行に対応します。 AWS Neuron 2.33 がネイティブ PyTorch サポート、Neuron Observer などの新機能を追加 AWS Neuron 2.33 がリリースされました。最大の変更点は、AWS Trainium 向けのネイティブ PyTorch バックエンドである TorchNeuron のパブリックベータ提供です。torch-xla を経由せず、.to(“neuron”) と指定するだけで標準の PyTorch コードを Trn2 / Trn3 インスタンス上で eager mode または torch.compile で実行できます。あわせて、Trainium の稼働状態の異常を 1 秒未満で検知する Neuron Observer、vLLM 0.29.0 対応、Wan2.2 動画生成向け vLLM Omni Neuron plugin、NKI Library への 25 個の実験的カーネル追加が含まれます。また、Neuron 2.34 で Trn2 / Trn3 の Torch/XLA 推論パスと NxD Inference がサポート終了になる予告が出ており、ネイティブ PyTorch パスへの移行計画が必要です。 AWS Transform が Amazon S3、EBS、EFS、FSx 向けのストレージ移行評価を追加 AWS Transform の移行評価 (migration assessment) 機能が、オンプレミスストレージの評価に対応しました。NetApp Digital Advisor エクスポートや RVTools ファイルなどのストレージインベントリをアップロードすると、NAS 共有、SAN LUN、直接接続ディスク、バックアップリポジトリの各ワークロードを Amazon S3、Amazon EBS、Amazon EFS、Amazon FSx (NetApp ONTAP、Windows File Server、OpenZFS、Lustre) に自動でマッピングし、サイジングとコスト予測を含む TCO ビジネスケースを生成します。Single-AZ と Multi-AZ、コスト最適化とパフォーマンス最適化といった What-if シナリオを比較でき、結果についてチャットで追加質問もできます。評価機能は無料で、AWS Transform が利用可能なすべてのリージョンで提供されます。 10/22(木) Amazon SageMaker AI が Muse Glimmer、Qwen 3.8、Ministral 3 モデルのサーバーレスモデルカスタマイズをサポート Amazon SageMaker AI のサーバーレスモデルカスタマイズに、Meta の Muse Glimmer 30B、Alibaba の Qwen 3.8 27B、Mistral AI の Ministral 3 (3B / 8B / 14B) が追加されました。これらのモデルに対して、SFT (教師ありファインチューニング)、DPO (直接選好最適化)、RFT (強化ファインチューニング) の 3 手法を、LoRA またはフルファインチューニングで実行できます。インフラのプロビジョニングとトレーニングのオーケストレーションは SageMaker AI が管理するため、GPU クラスタの運用なしに従量課金でモデルを適応できます。利用可能なリージョンはバージニア北部リージョン、オレゴンリージョン、東京リージョン、アイルランドリージョンの 4 つです。 AgentCore Gateway が Bedrock InvokeModel API とモデルフォールバックに対応 Amazon Bedrock AgentCore Gateway の推論エンドポイントが、Amazon Bedrock の InvokeModel および InvokeModelWithResponseStream API に対応しました。既存の Bedrock SDK (boto3 の bedrock-runtime クライアントなど) は endpoint_url をゲートウェイに向けるだけで、OpenAI や Anthropic を含む複数のモデルプロバイダーに 1 つの統制されたエンドポイント経由でアクセスできます。あわせてモデルフォールバックルーティングが追加され、プライマリの宛先がスロットリング、容量不足、到達不能のときに、ゲートウェイがルールで定義した代替の宛先へ自動で切り替えます。サーキットブレーカーが組み込まれており、障害中の宛先をスキップして無駄な試行による遅延を抑えます。中国リージョンを除く、AgentCore Gateway が利用できるすべてのリージョンで利用できます。 AWS Interconnect – last mile の Megaport とのプレビュー提供を発表 AWS は、ブランチオフィス、データセンター、リモート拠点を AWS にプライベート接続するマネージドサービス AWS Interconnect – last mile について、Megaport をパートナーとするプレビュー提供を発表しました。AWS マネジメントコンソールからリージョン、帯域幅、Direct Connect Gateway ID、パートナーのサブスクライバー ID を指定するだけで接続を作成でき、BGP ピアリング、VLAN、ASN の設定は自動化されます。2 つの物理サイトにまたがる 4 本の冗長接続が自動的にプロビジョニングされ、99.99% の SLA が提供されます。プレビューはサンノゼと北バージニアの 2 メトロで利用でき、北カリフォルニアリージョンとバージニア北部リージョンに接続できます。 AWS Continuum for code vulnerabilities が一般提供開始 AWS は、コード脆弱性の発見・検証・優先順位付け・修復を自動化する AWS Continuum for code vulnerabilities の一般提供を開始しました。AWS 環境からリソーストポロジー、IAM の関係、ネットワーク到達性を含むコンテキストグラフを構築し、検出した脆弱性を隔離サンドボックスで実際にテストして悪用可能かを確認します。悪用可能性の証拠とブラストラディウス評価を添えた修正パッチを、GitHub の Pull Request または Amazon S3 へのパッチファイルとして届けます。料金はコード 100 万行あたり月額 200 USD からの段階制コンテキスト料金と、1 推論ユニットあたり 10 USD の従量料金の 2 軸です。Amazon GuardDuty や AWS Security Hub など既存のセキュリティサービスと併用する前提で設計されています。 今週は GuardDuty や AWS Continuum for code vulnerabilities といったセキュリティ強化から、AWS Transform によるネットワーク・ストレージ移行支援、SageMaker のモデルカスタマイズまで、守りと攻めの両面でアップデートが広がった印象です。re:Invent を目前に控え、各サービスが着々と足場を固めているのを感じますね。来週はどんな発表が飛び出すでしょうか。それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

はじめに 対象読者 前提条件 levはJevと同じ話し方をする、別会社のオープンモデル READMEによれば公開データのみで学習、精度はInterfazeの測定でJevの7ポイント下 BERTの分類器と違い、質問をリクエストのたびに書ける T4 1枚で動くが、16GBに収めるにはlevの手直しが要った 起動とリクエスト 長い入力では、GPUメモリが2か所で溢れた CPUでは1回15分を超えた マルチエージェントでは、合否と選定だけをlevに回した つまずいたのは、答えをワークフローに載せる変換だった 今回の1回では、Claudeの利用料は56%減ったが、中身のない成果物も合格にした おわりに 参考リンク 執筆者 商標 はじめに NTT西日本の辻本です。 文章を書かずに「判断」だけを返すオープンモデル 「lev」 を、マルチエージェントの判断役として試した結果 を紹介します。AI社員だけで会社を回すOSS 「OneManCompany」 に組み込み、成果物の合否と3案からの選定をlevに任せました。同じタスクを1回ずつ走らせて比べると、今回の条件では、Claudeの利用料は定価換算で$2.92から$1.29に下がりました。一方でlevは、中身のない成果物も合格にしています。この削減には、合格にしてはいけない成果物を通したぶんも含まれています。本記事では、levの仕組みとBERT（Bidirectional Encoder Representations from Transformers）による分類との違い、GPU（NVIDIA T4）での自前ホスト、そして実測から考えたLLM（大規模言語モデル）との使い分けを順に説明します。 きっかけは、判断特化モデル「Jev」の一般提供でした。マルチエージェントでは、成果物を書く呼び出しのほかに、合否や採否を決めるだけの呼び出しが多く発生します。後者を専用の小さなモデルに任せたら、費用はどれだけ減り、判断の質はどう変わるのか。それを確かめたくて手を動かしました。 なお、本記事中で扱うサービスやモデル（Jev、lev、Claudeなど）に関する記載は2026年9月時点の情報に基づきます。また、動作結果と費用は筆者の実行環境・設定に依存し、比較は各条件1回ずつの実行によるものです。記事内で掲載しているコードは、理解しやすさを優先した簡略版（抜粋）です。 対象読者 マルチエージェントを組んでいて（または組もうとしていて）、APIの利用料を下げたい方 判断（分類・合否・選択）だけを返すモデルの使いどころを知りたい方 BERTのような分類モデルとLLMの違いを、実例で確かめたい方 前提条件 項目 内容 GPUマシン Azure Standard_NC4as_T4_v3 （NVIDIA T4 16GB、4 vCPU）、従量課金で$0.768/時（2026年9月時点、筆者が使ったリージョンの価格） OS / Python Ubuntu 22.04 / Python 3.12 lev 0.1.1（ Abhinavexists/lev のコミット cf104b6 ） langchain-typesafe 0.0.1a3 OneManCompany コミット 3fde188 （2026年8月26日） 生成用のLLM Claude Haiku 4.5（ claude-haiku-4-5-20251001 ） 検証日 2026年9月27日 levはJevと同じ話し方をする、別会社のオープンモデル TypeSafe AIが2026年9月に一般提供を始めた 「Jev」 は、文章を生成しない判断特化のモデルです。返すのは「選択」「Yes/No」「採点」の3種類の答えと、その確率だけです。TypeSafe AIはこの種類のモデルを「System One」と呼んでいます。 私は最初、このJevをマルチエージェントの判断役にするつもりでした。ところが申し込みが集中しているのか、ウェイトリストに登録しても順番が回ってきませんでした。Vercel AI Gateway経由でも呼べると知って試してはみましたが、 429 Too Many Requests が続き、時間を空けても実験を最後まで通せませんでした。そこで、同じAPIで動いて手元に置けるlevに切り替えました。 levは、Jevと同じAPIプロトコル（ /v1/systemone ）で応答するオープンウェイトのモデルです。中身はQwen3.5-4Bに、約200MBのLoRA（Low-Rank Adaptation）アダプタを乗せたものです。LoRAアダプタは、元の重みは変えずに差分だけを学習した追加部品です。ライセンスはApache-2.0で、重みはHugging Face（ interfaze-ai/lev ）にあります。作ったのはInterfazeという会社で、GitHub（ InterfazeAI/lev ）のREADMEには次の一文があります。 Not affiliated with or endorsed by TypeSafe AI. TypeSafe AIはJevの学習方法も重みも公開していません。つまりlevは、Jevの中身を知らないまま入出力の形に合わせて作られたことになります。TypeSafe SDK向けのコードは base_url を差し替えるだけでlevにつながりますが、互換なのは通信の形までです。 Interfazeによるlev公開の告知（出典： Interfaze公式Xの投稿 、Xの日本語自動翻訳で表示） なお、告知には「Jev、ついにオープンソース化」とありますが、前述の通り、levはJev本体を公開したものではありません。性能についての表現も、Interfaze自身によるものです。 READMEによれば公開データのみで学習、精度はInterfazeの測定でJevの7ポイント下 levのREADMEには「29の公開データソースから学習データを作り、評価用ベンチマークS1Benchの13サブセットと重なるものは除いた」とあります。Jevの出力を学習に使う、いわゆる蒸留ではなく、公開データだけで作ったという説明です。 そのぶん精度はJevに届いていません。Interfaze自身の測定（S1Bench全13サブセットの平均正解率）では、Jevが76.1%、levが68.9%でした。第三者のリーダーボードJevBench（2026年10月6日に確認した公開版v1.5.4）にlevは載っておらず、差を示せるのはこのInterfaze自身の測定だけです。なお、JevBenchには「lev-350m」という名前のモデルが載っていますが、作者もベースモデルも異なる別のモデルです。 今回試した範囲では、levにしかない利点もありました。Vercel経由（npmの ai パッケージ7.0.116の experimental_evaluate ）でJevを呼んだときには、判断の確信度（ confidence ）が返ってきませんでした（ほかの呼び方では確かめていません）。levでは返ります。 BERTの分類器と違い、質問をリクエストのたびに書ける 「判断だけを返すモデル」と聞いて、私が最初に思い浮かべたのはBERTのテキスト分類でした。BERTで分類器を作るときは、「返金・技術・営業」のようなラベルを先に決め、そのラベル専用の出力層を学習させます。ラベルを1つ足すだけでも、データを集めて学習し直すことになります。 levでは、質問も選択肢もリクエストの中に自然文で書きます。次の1リクエストには、Yes/No型（ noul ）と選択型（ choice ）の2問が同居しています。 { " state ": " 客から二重請求されたので返金してほしいという問い合わせが来た。 ", " questions ": { " should_refund ": { " type ": " noul ", " instructions ": " この問い合わせは返金対応すべきか " } , " route ": { " type ": " choice ", " instructions ": " どの窓口に回すか ", " criteria ": { " billing ": " 請求・返金 ", " tech ": " 技術的な不具合 ", " sales ": " 契約・見積もり " }} } } 明日「解約窓口」を足したくなったら、 criteria に1行書き足せば済みます。再学習はいりません。 ラベルを実行時に渡すだけなら、NLI（文と文の含意関係の判定）を使うゼロショット分類器でもできます。LLMに構造化出力で答えさせる手もあります。levが違うのは、4B規模の生成モデルが長い状態文を読んだうえで、文章を1トークンも書かずに確率だけを返す点です。土台が分類用のBERT（Encoder）ではなく生成用のQwen（Decoder）なので、質問文を読んで答える力はLLMから引き継いでいるはずです。私はlevを、固定の分類器というより「判断の出力に特化した小型LLM」と捉えています。 levの答えは確率で返ってくるので、その値をそのまま「どこから合格とするか」の線引きに使えます。執筆時点のClaudeのAPIではトークンの確率を取り出せないので、ここはClaudeに直接聞く場合との違いになります。 Yes/No型で主に見る値は2つです。 noul ：Yes寄りの度合い（0〜1）。9段階の評価を確率で重み付けした平均です。合格の線を引くときに使います confidence ：答えがどれだけ1つに偏っているか（0〜1）。1に近いほど、モデルの答えがはっきりしています 選択型では、選んだ選択肢と、選択肢ごとの確率が返ります。 実装の詳細 ：levは内部で、9段階の評価（0が「強くNo」、8が「強くYes」）それぞれの確率を probabilities として返します。 noul は、段階を0〜1に直して確率で重み付けした平均（Σ i/8 × pᵢ）です。 confidence はlevの実装（ model.py の _gini ）で計算され、全段階が同じ確率なら0、1つの段階に集中すれば1になります。 T4 1枚で動くが、16GBに収めるにはlevの手直しが要った この章は、levをGPUで動かすための手順とつまずきの記録です。費用と判断の質の結果だけを知りたい方は、次の章まで飛ばして構いません。 T4を選んだのは、今回すぐに用意できたGPUのうち最小のものだったからです。 起動とリクエスト インストールと起動は2行で済みます。インストール元は、Hugging Faceのモデルカードに書かれているメンテナ個人のリポジトリ（ Abhinavexists/lev ）です。検証は、業務環境から切り離した検証用のVMで行いました。 pip install "lev[serve] @ git+https://github.com/Abhinavexists/lev@cf104b6#subdirectory=packages/lev" lev serve --checkpoint interfaze-ai/lev --host 127.0.0.1 --port 8100 lev serve の起動ログは次の通りです（進捗バーの行は省略）。 lev serveの起動ログ（CPU環境で撮影） causal_conv1d はGPU向けの高速な計算ルーチンで、入っていないと遅い標準実装に切り替わります。GPU上で flash-linear-attention を入れて試しましたが、この環境では速くなりませんでした。 lev serve には認証がないので、ポートは外に開けていません。呼び出し側のVMからは、SSHのポートフォワードでつなぎました。 ssh -f -N -L 127.0.0.1:8100:127.0.0.1:8100 <ユーザー名>@<GPU VMのアドレス> 前の章で示した2問のうち、返金の質問だけを投げると、こう返ります。 lev serveへのcurlとレスポンス（CPU環境で撮影。レスポンスの形はGPUと同じ） 各値の意味は前の章で説明した通りです。ここでは「8」が0.93を占めるので、 noul は0.95になりました。 応答時間は、単体で測ると短い質問で0.42秒でした（起動後の1回目だけ約5秒）。1,734トークンのレビュー文では約6秒、2,196トークンで3案を比べる選択型では約12秒かかりました。後述の比較実行では、レビューの入力が約3,800〜4,400トークン、選定が約1,000トークンでした。その実行での秒数は記録していません。TypeSafe AIが公表しているホスト版Jevの150ms前後には遠く及びません。それでも単体計測の範囲では、マルチエージェントの1ステップとして待てる長さでした。 長い入力では、GPUメモリが2か所で溢れた 最初は、長いレビュー文を送るとGPUのメモリ不足（ CUDA out of memory ）で、HTTPステータス500が返りました。原因は2つありました。 1つ目は語彙の大きさです。levの実装は、選択肢ごとに入力を1行ずつ複製して一括で計算します。そのとき、入力の全位置について、次に来るトークンの候補24万8,320語それぞれのスコア（logits）を出していました。実際に使うのは各行の末尾だけなのに、この確保だけで4.55GiBを要求していました。GiBは2の30乗バイトで、PyTorchのエラーメッセージがこの単位で出すため、そのまま載せています。T4の16GBは、nvidia-smiで見ると約15GiBです。2つ目は注意機構（attention）の計算で、全行を一度に流すと、行数×文長の2乗に比例するメモリを取ります。こちらは3.08GiBを要求して落ちました。 どちらも lev/model.py の _forward_single を数行直せば避けられました。必要な末尾の位置だけlogitsを出させ（ logits_to_keep ）、行を小分けにして流します。 LEV_MICRO_BATCH は、このとき私が足した環境変数で、上流のlevにはありません。 first_last = 0 if want_hidden else min ( len (r) - 1 for r in rows[:n_real]) keep = width - first_last # 末尾の必要な位置だけスコアを出す chunk = int (os.environ.get( "LEV_MICRO_BATCH" , "2" )) # 独自に追加 for start in range ( 0 , batch.shape[ 0 ], chunk): # 行を小分けにして流す out = self.model(input_ids=batch[start:start + chunk], attention_mask=attention[start:start + chunk], use_cache= False , logits_to_keep=keep) logit_parts.append(out.logits) 最終的に LEV_MICRO_BATCH=1 （1行ずつ）で落ち着きました。GPUメモリの使用量は約9.2GBで、直す前と後で出力の値（ noul 、 confidence 、選ばれた案）が一致することを確かめてあります。 CPUでは1回15分を超えた GPUに移る前は、CPU 4コア・メモリ15GBのVMで動かしていました。スレッド数を明示すると最初の応答は約7分から約23秒に縮みましたが、レビュー文のような長い入力は1回15分を超えました。 langchain_typesafe の TypeSafeClassifier はHTTPタイムアウトの既定値が30秒なので、CPUで試すならそこも延ばしておきたいところです。30秒で切れたリクエストをlevは計算し続け、そこへ再送が積み上がったとみています（量は測っていません）。最後は、メモリ不足でLinuxがプロセスを強制終了する仕組み（OOM Killer）にlevを止められました。 マルチエージェントでは、合否と選定だけをlevに回した 題材は OneManCompany（OMC） です。「AI社員だけの仮想会社」を再現するOSSで、エージェントの処理手順をグラフとして組むライブラリLangGraphで作られています。CEOがタスクを投げると、秘書役のEA（Executive Assistant）が受け取り、COOがサブタスクに分けて部下に割り振ります。COOは上がってきた成果物をレビューして、合格か差し戻しかを決めます。 OMCのLLM呼び出しには、文章や成果物を書く「生成」と、合否や採否を決める「判断」が混ざっています。生成はこれまで通りClaudeに任せ、判断だけをlevに回しました。具体的には、OMCでモデルを生成する関数 onemancompany.agents.base.make_llm を差し替えました。レビュー用のノード（LangGraphのグラフ上の処理単位）を実行している間だけ、この関数がlevを呼ぶ薄いラッパーを返します。ラッパーは、OMCが組み立てたレビュー文を state に入れ、案ごとにYes/Noを1問ずつ聞きます。 questions = { f "accept_{i}" : Noul(instructions=f "「{_label(s)}」の成果物は受け入れ基準を満たしているか" ) for i, s in enumerate (self.subtasks) } 全案が合格になった回だけ、続けて「どれを採用するか」を選択型で聞きます。levの答えは、OMCのエージェントが普段呼んでいるツール（ accept_child / reject_child ）の呼び出しや、ノードの最終回答に変換して返します。OMC側は、Claudeが判断したときと同じ経路でそれを実行します。 つまずいたのは、答えをワークフローに載せる変換だった つまずきのうち、いちばん影響が大きかったのは、最初の設計で「3案から1つ選んだら、残りの2案は reject_child で差し戻す」としていたことです。選ばれなかった案を落とすだけのつもりでした。 ところが、OMCの差し戻しは「作り直せ」という意味です。落選した案はClaudeに書き直され、再挑戦の上限に達すると「失敗」扱いになりました。親タスクは失敗した子を抱えたまま止まりました。その実行ではClaudeの利用料が$2.85まで膨らみ、判断もClaudeに任せた構成（次の章で比べるBefore）とほぼ同じ額になっていました。OMCには「作り直せ」はあっても、「今回は見送り」を表す状態がなかったのです。 最終的には、3案とも合格にしたうえで、どれを選んだかを合格メモに残す形にしました。判断もClaudeに任せたときも、Claudeは3案とも合格にし、選定は報告で示していたので、その振る舞いに合わせたことになります。合否は案ごとのYes/Noで聞き、全案が合格した回だけ別に「どれを採用するか」を聞く、という前の節の形は、こうして決まりました。 判断の答えそのものより、それをワークフローのどの状態に対応づけるかで結果が大きく変わります。これが今回いちばん身にしみた点です。 今回の1回では、Claudeの利用料は56%減ったが、中身のない成果物も合格にした 題材のタスクは、社内向け「備品貸出管理AIアシスタント」（検証用の架空のテーマ）の訴求コピーづくりです。コスト・セキュリティ・利便性の3つの切り口で案を作り、COOが1つを採用します。このタスクを、判断もClaudeに任せるBeforeと、判断はlevに任せるAfterで1回ずつ走らせました。OMCの設定（ OMC_DEBUG=1 ）もそろえてあります。回数が1回ずつなので、以下の数字にばらつきの評価は含まれていません。削減率も今回のタスクと設定での値で、合格の線の位置、OMCのループの長さ、タスクの内容、社員の失敗や書き直しの有無によって変わります。 Before（判断もClaude） After（判断はlev） Claudeの利用料（全呼び出し、定価換算） $2.92 $1.29 うち判断（レビュー3回。最後の1回は選定を含む） $1.46 $0 levの呼び出し なし 4回（合否3回、選定1回） 依頼から最後のCOO判断まで 3分47秒 2分03秒 GPU代（その時間ぶん） なし 約$0.03 コピーが実際に書かれた案 3案 1案 採用された案 コスト訴求 セキュリティ訴求 利用料は、OMCのデバッグログ（ debug_trace.jsonl ）に残る全呼び出しのトークン数を、Haiku 4.5の定価（入力$1、出力$5／100万トークン）で換算しました。プロンプトキャッシュの割引は考えていないので、上限寄りの値です。 差額の内訳は次の通りです。 内訳 Before − After 判断（レビュー3回） $1.46 社員の作業 $0.25 EAとCOOのタスク分解 −$0.08 合計 $1.63 いちばん大きいのは判断の$1.46です。Beforeでは最後のレビューだけで約75万トークンを読み、約1万トークンの選定レポートを書いていました。OMCのエージェントは、Claudeに「考える、ツールを呼ぶ、結果を読む」を繰り返させるReAct（Reasoning and Acting）というループで動きます。OMCは1回ごとに、役割ガイドとツール定義、それにレビュー文（各案の本文・受け入れ基準・検証結果）を含むそれまでのやり取りを、まとめてClaudeに送り直します。ループが回るほど入力が積み上がり、1ノードで26万〜75万トークンになりました。levへの入力は1回4,000トークン前後で、最後のレビューでClaudeが読んだ量の200分の1ほどです。 ただし、この$1.46には2つの効果が混ざっています。判断専用のモデルに替えた効果と、ReActのループをやめて1回の呼び出しで答えさせた効果です。Claudeを1回だけ呼んで、構造化出力で合否を返させる構成でも、費用はかなり下がるはずです（今回は試していません）。levならではの違いは、費用よりも、答えを確率で受け取れて合格の線を自分で引ける点にあると考えています。 社員の作業の$0.25は、手放しでは喜べません。Beforeでは書き直しが1回あり、Afterでは2案がコピーを書かずに終わっているので、この部分は失敗によって安く見えている分です。所要時間が短いのも、同じ理由が効いています。 Afterでは、コスト訴求と利便性訴求を担当した社員（Claude）がコピーを書かず、「コピー作成は自分の役割外だ」とCEOにエスカレーションする報告を返していました。levはこの2件を合格にしました。今回のラッパーの設定では、 noul が0.75の案も合格になっていました。返ってきた noul は次の通りです。 案 実際の中身 noul セキュリティ訴求 コピーが書かれている 0.96 コスト訴求 エスカレーションの報告だけ 0.92 利便性訴求 エスカレーションの報告だけ 0.75 Beforeでも、コスト訴求の担当者が一度「スキルが足りない」という報告を返しました。Claudeはそれを差し戻して書き直させ、最終的に3案がそろいました。今回の3件を見る限り、levは成果物がコピーそのものか、報告にすぎないかを見分けられていませんでした。報告の体裁や受け入れ基準への言及に引っ張られたように見えます（原因は切り分けていません）。以前の別の実行でも、「キャンセルしました、指示待ちです」という報告を合格にしていました。 noul の並びには手がかりがあります。本物のコピーが0.96で最も高く、中身のない2件はそれより低い値でした。合格の線を0.95に引けば、この3件は正しく分けられた計算になります。ただし、これは結果を見てから決めた値で、1回の実行から言える話ではありません。 では、線を上げれば解決するかというと、そうとも言い切れません。コピーが1行もない報告に0.92が付き、本物との差は0.04しかありませんでした。今回の3件を線で分けられたのは、たまたまだった可能性があります。levがコピーと報告を見分けられていなかったこと自体は、線の位置では直りません。 また、0.95の線を使っていれば、中身のない2件はClaudeに戻され、書き直しも発生します。そのぶん利用料は$1.29より上がり、削減率は56%より小さくなっていたはずです。今回の56%は、levの見逃しを含んだうえでの数字です。 最後の選定では、levは唯一コピーが書かれていたセキュリティ訴求案を確率0.76で選びました。このときの confidence は0.41でした。前述の通り、 confidence は分布の偏り具合なので、1位の確率とは別の値になります。3案の確率（0.76、0.15、0.09）から計算すると、ちょうど0.41になります。 T4のVMを立てっぱなしにすると、$0.768×24時間で1日約$18.4かかります。今回の差額からGPU代を引くと1回あたり約$1.60で、失敗の分（約$0.25）も除くと約$1.35です。この金額で試算すると、元が取れるのは、この種のタスクを1日に12〜14回以上流すときです。それより少ないなら、使うときだけVMを起動するほうが安く済みます。 おわりに levに判断を任せた部分の利用料は消えましたが、levが見逃したのは「成果物がそもそも出ているか」でした。levに任せられる判断と、任せられない判断の境目から、私は次のような分担を考えています。 文章や成果物を書く仕事は、LLMに任せる 問いと選択肢を言葉で書き切れる判断は、levに任せる候補になる（今回確かめたのは合否と3案からの選定だけで、窓口の振り分けのような判断は実験していない） levの noul が線に届かない判断や、中身が伴っているかを見る判断（今回ならエスカレーションの報告をコピーと取り違えた件）は、LLMに戻す 3つ目の線をどこに引くかは、今回の1回だけでは決められません。今回の3件なら、0.95に線を引けば、本物のコピー（0.96）だけが合格になります。中身のない2件（0.92と0.75）はClaudeに戻せたことになります。ただし、これは結果を見てから引いた線で、別のタスクや別の実行でも通用するとは限りません。そこで今後は、levの noul が一定値を下回ったレビューだけをClaudeに戻す構成で、利用料と見逃しの両方を測ってみたいと考えています。線を高くすれば見逃しは減りますが、Claudeに戻す回数が増えて利用料も戻ります。両方を測りたいのは、その釣り合う点が分かれば、判断モデルを実務に入れるかどうかを数字で決められるからです。 参考リンク Introducing System One models and Jev（TypeSafe AI） lev公開の告知（Interfaze公式X） lev（Hugging Face） InterfazeAI/lev（GitHub） Abhinavexists/lev（GitHub、インストール元） OneManCompany（GitHub） LangGraph（公式ドキュメント） 執筆者 辻本傑（NTT西日本株式会社 ビジネス営業本部 バリューデザイン部 システム開発部門） ビジネスチャットの開発・運用に携わっています。C#やクラウドが好きで、最近はROS2を利用したロボット開発にも関心があります。 認定スクラムマスター（CSM） 商標 Jev は、TypeSafe AI が提供するモデルです。 lev は、Interfaze が公開しているモデルです。 Qwen は、Alibaba Cloud が開発・公開しているモデルです。 PyTorch は、The Linux Foundation の商標です。 Claude は、Anthropic PBC の商標または登録商標です。 Microsoft Azure は、米国 Microsoft Corporation の商標または登録商標です。 NVIDIA は、NVIDIA Corporation の商標または登録商標です。 Ubuntu は、Canonical Ltd. の商標または登録商標です。 Linux は、Linus Torvalds 氏の米国およびその他の国における登録商標です。 Python は、Python Software Foundation の登録商標です。 GitHub は、GitHub, Inc. の商標または登録商標です。 Hugging Face は、Hugging Face, Inc. の商標または登録商標です。 LangChain および LangGraph は、LangChain, Inc. の商標または登録商標です。 Vercel は、Vercel Inc. の商標または登録商標です。 X は、X Corp. の商標または登録商標です。 その他、本文中に記載されている会社名・製品名・サービス名などは、各社の商標または登録商標である場合があります。