AIニュース速報（2026年9月26〜27日）｜高性能AIモデルの「使い過ぎ」はモデル使い分けでトークンコストを最大44%抑制できる可能性、1800件の「非人間ID」をどう統制するかJBCCの実践、Akamaiは「AIのふるまい」制御に警鐘、GPT-6の価格競争、AIが医療費を押し上げると保険団体が指摘まで解説

2026年9月27日時点で振り返る9月26〜27日の2日間のAIニュースは、世界3本・日本6本の計9本です。本記事が最大の話題として取り上げるのは、高性能AIモデルの「使い過ぎ」によるトークンコストの増大です。企業のAI活用が進む中で、高性能モデルへの過度な依存がコストを押し上げていることが課題となっており、タスクに応じてモデルを使い分けることで、コストを最大44%抑制できる可能性があるとの分析が示されました。

同じ2日間には、AIエージェントの統制をめぐる話題も2本続きました。AIエージェントやAPIに割り当てられる「非人間ID」をどう統制するかというJBCCホールディングスの実践と、従来のID・アクセス管理に加えてAIエージェント自体の「ふるまい」を制御するガバナンスが必要だとするAkamaiのレポートです。本記事では、この2つを中心に、GPT-6の価格競争、脱VMwareとITインフラ人材不足、医療費、AIコマース、デジタルアバターまでを整理します。報道の要約で示された情報が少ない項目もあるため、記事で示されていないことは示されていないと明記し、筆者の見解は分けて書きます。

AIニュース 2026年9月27日の全体像：AIのコストを「使い分け」で抑え、AIエージェントを「ID」と「ふるまい」で統制する2日間

日本語メディアでの報道日が9月26日にかかるMicrosoftの「Copilot」アプリの刷新とCodexの約1時間の障害は、前回記事（2026年9月25〜26日のAIニュース）で扱ったため、本記事の対象から外しています。

9本をテーマごとに束ねると次のとおりです。

日本側の6本のうち4本に共通しているのは、AIを使うかどうかではなく、使い始めた後にどう管理するかが問われていることです。高性能モデルの使い過ぎによるコストの増大、AIエージェントやAPIが持つIDの放置、エージェントのふるまいの制御、そしてAIに任せきれないITインフラの運用。価格競争の2本は、本連載が9月21〜24日回で扱ったClaude Opus 5.5とGPT-6 Sol・Lunaの発表の続報にあたります。

世界側の3本は、AIが病院の保険請求、商品の購入、自分自身の分身というお金と本人に近い場所に入り込んでいることを示しています。以降では、最大の話題であるトークンコストとモデル使い分けから見ていきます。

トークンコストの抑制：高性能AIモデルの「使い過ぎ」に、モデル使い分け（モデルルーティング）で最大44%の可能性

この2日間で本記事が中心に据えるのが、＠ITが報じた高性能AIモデルの「使い過ぎ」です。報道の要約は短く、数字は1つだけですが、本連載が追ってきたAIのコストという論点に「どう下げるか」という方向を加える内容です。なお、タスクに応じて処理するモデルを振り分けることは一般にモデルルーティングと呼ばれますが、この言葉は記事の要約で使われているものではなく、本記事の整理のための呼び方です。

記事で示されたこと：高性能モデルへの過度な依存と、最大44%の抑制可能性

＠ITによると、企業のAI活用が進む中、高性能モデルへの過度な依存によるトークンコストの増大が課題となっています。そのうえで、タスクに応じてモデルを使い分けることで、コストを最大44%抑制できる可能性があるとの分析が示されました。記事の見出しは、この状態を高性能AIモデルの「使い過ぎ」と表現しています。

押さえておきたいのは、44%が「最大」であり、「可能性がある」という表現で示されていることです。条件がそろった場合の上限の見込みとして読むのが妥当です。

ソース：＠IT

記事で示されていないこと：分析の主体、算出方法、比較の基準、品質への影響

元にした報道の要約からは、次の点が読み取れません。

• 分析の主体：誰が行った分析なのか
• 算出方法：どのようなタスク群と利用量をもとに44%を算出したのか
• 比較の基準：何と比べて最大44%なのか。たとえば、すべてを高性能モデルで処理した場合との比較なのか
• 使い分けの対象：どのモデルとどのモデルを、どのような基準で使い分けたのか
• 品質への影響：使い分けによって回答の品質や人の手直しの量がどう変わったのか

とくに最後の点が実務では重要です。トークンコストが下がっても、人が直す時間が増えれば業務全体のコストは下がりません。44%を自社の削減見込みとして稟議に使うのは避け、自社のタスクで測り直す出発点として扱うことを勧めます。

本連載で追ってきたAIコストの流れ：価格、利用額、トークン消費量の可視化、そしてモデル使い分け

本連載の既報と今回の1本を並べると次のとおりです。

以下は筆者の整理です。話題は単価が下がる、利用額が見える、消費量を測る道具が出る、下げ方が示されると進んでいます。単価が下がっても、使う量が増えてその多くが高性能モデルに流れれば、総額は増え得ます。今回の分析が問題にしているのは、この使い方の偏りです。

タスクに応じたAIモデルの振り分けをどう考えるか（筆者の見解）

以下は筆者の見解で、記事が示した方法ではありません。使い過ぎが起きやすいのは、一番賢いモデルを既定にしておけば失敗しにくいという判断が、個々の利用者にとっては合理的だからだと考えます。回答の品質は利用者の手元に見えますが、トークンコストの請求は部署や会社の単位で届きます。品質とコストの責任が別の場所にある限り、放っておけば高性能モデルに寄っていきます。

モデルの使い分けは、この偏りを仕組みで戻す方法です。社内のAI利用を必要な能力の高さで分け、定型の情報抽出、分類、短い要約のように正解の形がはっきりしていて人が確かめやすいタスクは、軽量なモデルから試す候補にします。長い文書をまたぐ推論、設計の比較、顧客に出す文章のように誤りの影響が大きいタスクは、高性能モデルに残す候補です。そして軽量なモデルで失敗したときに上位モデルへ引き上げるルールを決めておけば、品質の下限を保ちながらコストを抑えられる可能性があります。

ただし、モデルが増えれば評価や切り替えの管理も増えます。利用量の多い上位数種類のタスクから始めるのが現実的です。進め方は後段の「日本企業への示唆」で整理します。

GPT-6の価格競争のその後：コスト半減、Claudeの猛追とオープンソースモデルの包囲網、Claude Opus 5.5とGPT-6 Sol・Lunaの振り返り

モデルの価格をめぐる2本は、いずれも新しいモデルの発表ではなく、本連載が9月21〜24日回で9月22日付の報道として扱ったClaude Opus 5.5とGPT-6 Sol・Lunaの発表を受けた続報と振り返りです。

コスト半減の新型「GPT-6」とClaudeの追い上げ、オープンソースモデルの台頭で企業向けAIの価格競争が激化

TechTarget ジャパンは、OpenAIがコストを大幅に引き下げた新型「GPT-6」系モデルを投入し、Anthropicの「Claude」の追い上げやオープンソースモデルの台頭を受けて、企業向けAIの価格競争が激化している実態を報じました。見出しは「コスト半減」「Claude猛追とOSS包囲網」という言葉を掲げています。

一方で、要約には具体的な数字や事例が示されていません。どのオープンソースモデルを指すのか、Claudeの追い上げをどの指標で見ているのかは読み取れないため、本記事ではこれ以上踏み込みません。見出しの「コスト半減」は、9月21〜24日回で扱った「前世代の半額」という報道と方向が一致しています。

ソース：TechTarget ジャパン

週末の振り返り：Claude Opus 5.5は「Fable 5.1」と同等の性能で実行コスト40%減、GPT-6 Sol・LunaはAPI価格をさらに50%引き下げ

ITmedia PC USERの週末まとめ記事は、Anthropicの「Claude Opus 5.5」と、同日にOpenAIが投入した「GPT-6 Sol」「GPT-6 Luna」を振り返っています。記事によると、Claude Opus 5.5は上位モデル「Fable 5.1」と同等の性能を保ちながら実行コストを40%低減し、GPT-6 Sol・LunaはAPI価格を前世代のプロモーション価格からさらに50%引き下げたとされます。

ソース：ITmedia PC USER

本連載の既報と今回の振り返りで、価格の書き方はどう違うか

9月21〜24日回で扱った報道と今回の週末まとめの書き方を、それぞれの言葉のまま並べます。

GPT-6 Sol・Lunaについて、今回の振り返りは値下げの基準を前世代の「プロモーション価格」と特定しており、9月21〜24日回で扱った「前世代『5.6』シリーズの半額」という報道より具体的な書き方になっています。どちらかの報道が誤りだと判断する材料は要約の範囲にはなく、プロモーション価格の期間や水準も示されていないため、本記事では新たな単価の計算は行いません。

価格競争は利用企業に何をもたらすか（筆者の見解）

以下は筆者の見解です。表で見たとおり、値下げの基準は記事によって書き方が変わります。何と比べるかによって、同じ「半額」や「4割減」の意味は変わります。値下げの見出しをそのまま自社の見積もりに使わず、自社のタスクを実際に流して1件当たりのコストを測ることが、9月21〜24日回から一貫した結論です。

もう1つは、価格競争がモデル使い分けの選択肢を広げることです。オープンソースモデルも台頭しているとされる中では、タスクごとに費用対効果のよいモデルを選ぶ余地が大きくなります。ただし、プロモーション価格のような条件を前提に長期の予算を組むと、条件が変わったときに見込みが崩れます。価格が変わってもモデルを入れ替えられる設計にしておくことが、価格競争の恩恵を受け続けるための備えになります。

AIエージェントのガバナンス：1800件の「非人間ID」をどう統制するか（JBCC）、Akamaiが警鐘を鳴らす「AIのふるまい」制御

AIエージェントの統制については、国内企業の実践と海外の事業者のレポートという異なる立場から2本の記事が出ました。1本はAIエージェントやAPIが持つIDの管理、もう1本はAIエージェントのふるまいの制御を扱っています。

JBCCホールディングスの実践：AIエージェントやAPIに割り当てられる「非人間ID」の統制と「AI Orchestration Platform」

TechTarget ジャパンによると、AIエージェントやAPIに割り当てられる「非人間ID」が管理されないまま放置され、サイバー攻撃の脆弱性となる問題が指摘される中、JBCCホールディングスが実践したID統制策が紹介されました。記事の見出しは「1800件の『非人間ID』をどう統制するか」と掲げ、JBCCの取り組みを「リスク防衛策」と表現しています。同社は、継続的なAI活用を支える「AI Orchestration Platform」の構築を進めているとされます。

一方で、要約からは、JBCCが具体的にどのような手順や仕組みでIDを統制したのか、1800件の内訳、AI Orchestration Platformの中身は読み取れません。

非人間IDとは、一般に、人ではなくシステムやプログラムに割り当てられるIDを指し、APIキー、サービスアカウント、アクセストークンなどがこれにあたります。見出しの1800件という数からは、非人間IDが千件単位にのぼり得ることがうかがえます。以下は筆者の見解ですが、それだけの数を作った人の記憶に頼って把握し続けるのは難しいと考えられます。

ソース：TechTarget ジャパン

Akamaiのレポート：従来のID・アクセス管理に加え、AIエージェント自体の「ふるまい」を制御するガバナンスを

キーマンズネットによると、Akamaiは、企業がAPIやシステムを横断する業務に自律型AIエージェントを活用する中で、従来のID・アクセス管理に加え、AIエージェント自体の「ふるまい」を制御するガバナンスが必要だと指摘するレポートを公表しました。記事の見出しは「AIに仕事を任せるほどセキュリティは困難に？」と問いかけています。

これはAkamai自身の見解を示したレポートで、「ふるまい」を具体的にどう制御するのか、どのような調査に基づくのかは要約からは読み取れません。なお、Akamaiは前回記事で、Anthropicと7年間で116億ドルのクラウド契約を結んだと報じられた企業でもありますが、今回のレポートとの関係は要約からは読み取れません。

以下は筆者の整理です。ID・アクセス管理が答えるのは「このエージェントは何にアクセスできるか」という問いです。ふるまいの制御が答えるのは、「アクセスできる範囲の中で、実際に何をしているか」という問いです。権限の範囲内でも、想定外の順序や量で操作が重なることはあり得ます。

ソース：キーマンズネット

本連載で追ってきたAIエージェントの統制：許可する範囲、IDの管理、ふるまいの制御

本連載の既報と今回の2本を並べると次のとおりです。右列は本記事の整理です。

以下は筆者の見解です。統制には「誰として動くか（ID）」「どこに入れるか（アクセス）」「入った先で何をするか（ふるまい）」という層があります。前回記事で扱った画像の無断投稿は、書き込める権限があれば、攻撃を受けなくてもデータが外に出ていき得ることを示しました。アクセスの管理だけでは防ぎにくい、ふるまいの問題です。

一方で、ふるまいがどのIDによるものかが分からなければ、止めることも記録をたどることもできません。JBCCの実践とAkamaiの指摘は別々の記事ですが、IDの把握とふるまいの制御は、どちらか一方では足りないという点で補い合っています。9月24〜25日回で述べたとおり、トークン消費の急な増加は想定外の動きの兆候でもあり得るため、コストとふるまいを同じ記録の上で見られるようにしておくと両方に効きます。

脱VMwareで顕在化したITインフラ人材不足：IaCとAIでどこまで補えるか

＠ITによると、VMware製品からの移行が進む中、ITインフラを任せられる人材の不足が顕在化しています。記事は、IaC（Infrastructure as Code）とAIを活用し、望ましいIT構成をコード化する作業をAIに担わせることで、担当者は設定のレビューや意思決定に集中できるとしています。一方で、AI任せの限界も指摘されています。見出しは「AI頼みで解決できるか」と問いかけています。

IaCは、一般に、サーバーやネットワークの構成を手作業の設定ではなくコードとして記述し、そのコードをもとに環境を構築・変更する手法を指します。構成がコードとして残るため、変更の差分を確かめたり、同じ環境を作り直したりしやすくなります。報道の要約からは、AI任せの限界として具体的にどのような点が挙げられているのか、人材不足の規模を示すデータ、どの移行先やツールを想定しているのかは読み取れません。

ソース：＠IT

この記事は、本連載が9月21〜24日回で扱った脱メインフレームの7割超が失敗に終わっているという特集と並べて読む価値があります。同回では、その背景として生成AIを使えば移行作業を容易に代替できるという「過信」が指摘されていました。移行の対象はメインフレームとVMwareで異なりますが、どちらも既存の基盤から移ることとAIへの期待が重なった話題です。

以下は筆者の見解です。記事が示す役割分担、つまりコード化はAIに、レビューと意思決定は人にという形は、人材不足への現実的な答えの1つだと考えます。ただし、レビューをする人には、コードに書かれた構成が何を意味し、変更すると何が起きるかを判断できる知識が必要です。AIが書いたコードを読めない人のレビューは、確認ではなく承認の形式になってしまいます。IaCとAIの組み合わせは手作業を減らせても、インフラの知識を持つ人そのものを不要にするわけではないと見るのが妥当です。

医療費を押し上げるAI：Blue Cross Blue Shield Associationが指摘する保険コーディングと治療内容の「明確な乖離」

TechCrunchによると、米大手保険団体Blue Cross Blue Shield Associationの分析は、病院が保険請求時にAIツールを利用した結果、過去2年間で医療支出が9億4200万ドル増加したとしています。患者が「複雑な病状」として記録されるケースが急増しており、AIによる保険コーディングと実際の治療内容との間に「明確な乖離」があると指摘されています。

ここで押さえておきたいのは、9億4200万ドルという数字も「明確な乖離」という評価も、保険金を支払う側の団体による分析と主張だということです。TechCrunchの記事も、保険業界側の指摘として伝えています。報道の要約からは、病院側がこの指摘にどう応じているのか、分析の方法、どのようなAIツールが使われたのかは読み取れません。したがって、AIが不当に請求額を膨らませていると断定することはできず、本記事ではあくまで保険団体の分析として扱います。

ソース：TechCrunch

以下は筆者の見解です。この件は医療に限らず、AIに請求や申請の書類を作らせる業務すべてに通じる論点を含んでいます。AIは与えられた目的に沿って記録を整えることが得意です。その目的が「漏れなく記録する」ことであっても、結果として記録の内容が実態より重く見えるようになれば、書類を受け取る側は記録と実態の食い違いを疑います。今回の件で問われているのは、AIの出力の正確さというより、記録と実際に行われたことが対応しているかを、後から確かめられるかです。

日本企業でも、経費精算や各種の申請、取引先への請求書類の作成などにAIを使う場面は考えられます。そうした業務にAIを入れる際は、AIが作った記録がどの事実に基づいているのかをたどれるようにしておくこと、そして記録の傾向が導入の前後で急に変わっていないかを確かめることが、受け取る側からの信頼を保つための備えになります。

AIが買い物の入口に：GoogleがインドでGeminiとAIモードからFlipkartの商品を購入できる機能をテスト

TechCrunchによると、Googleは、Walmart傘下のインドEC大手Flipkartの商品を、GeminiおよびAIモード経由で直接購入できる機能のテストをインドで開始しました。AIサービスを商品発見から購買（トランザクション）へと拡張する狙いがあり、検索大手のAIコマース戦略の一環とみられています。

報道の要約からは、テストの対象となる利用者の範囲や期間、決済の仕組み、Flipkart側がこのテストにどう関わっているのか、インド以外の地域に広げる予定があるのかは読み取れません。「AIコマース戦略の一環」という位置付けも、「とみられる」という推測の形で示されているものです。

ソース：TechCrunch

AIアシスタントを通じた買い物は、本連載で続けて扱ってきた話題です。9月21〜24日回では、Amazon.comがMetaの「Muse」による商品購入操作をブロックし、「無許可のAIエージェントによる継続的なアクセスはAmazon利用規約に違反する」とのエラーが表示されることを扱いました。9月25〜26日回では、Museが早期アクセスプログラムの対象にショッピング連携の拡充を含めたことを扱っています。今回のGoogleのテストは、AIサービスを商品発見から購買へ広げようとする動きの1つとして並べられます。

以下は筆者の見解です。EC事業者や商品を扱う企業にとって、AIアシスタントが検索や比較だけでなく購入の入口になれば、利用者がサイトを直接訪れる前に選択が終わる場面が増えると考えられます。自社の商品情報がAIに正しく読み取られる形で整っているか、外部のAIエージェントからのアクセスをどう扱うかの方針を持っているか。AmazonとGoogleの事例は立場が異なりますが、どちらもその判断が避けられなくなりつつあることを示しています。

自分の「AIクローン」と話す：TechCrunch記者の対話型デジタルアバターと、Synthesia・D-ID・HeyGen・Colossyan

TechCrunchの記者が、自分自身と対話できるインタラクティブなデジタルアバターを作成し、その体験と「AIクローン」がもたらす影響について報告しました。記事は、Synthesia、D-ID、HeyGen、Colossyanなど、デジタルアバター系スタートアップの盛り上がりを背景にしたものです。

報道の要約からは、記者がどのサービスを使ってアバターを作ったのか、作成にどれだけの時間や素材が必要だったのか、記者がAIクローンの影響をどう評価したのかは読み取れません。挙げられた4社も、分野の盛り上がりの例として名前が並べられているもので、各社の機能や違いは示されていません。

ソース：TechCrunch

デジタルアバターは、本連載でここ数日続けて登場しています。9月24〜25日回では、Googleが「Gemini 3.8 Live with Live Avatar」を企業向けのGemini Enterpriseで一般提供し、画像1枚から自然に受け答えするアバターを生成できるようになったことを扱いました。9月25〜26日回では、MetaがMuseの早期アクセスプログラムの対象にビデオチャット用のデジタルアバターを含めたことを扱っています。企業の接客、個人向けアシスタント、そして本人の分身へと、アバターが使われる場面が広がっています。

以下は筆者の見解です。企業がデジタルアバターを使う場面、たとえば経営者や社員の分身に説明や案内をさせる場面では、誰のアバターを、誰の同意のもとで、どこで使うかを決めておく必要があります。本人の顔や声で話すアバターは、受け手から見れば本人の発言に近い重みを持ちます。9月24〜25日回で扱ったElevenLabsのCEOのインタビューでも、AIによる顧客対応であることの開示のあり方が語られていました。アバターがAIであることをどう示すか、本人が言っていないことを話したときに誰が責任を持つかは、導入の前に決めておくべき論点です。

日本企業への示唆：モデル使い分け、タスク単位のコスト測定、非人間IDの棚卸し、IaC×AIのレビュー体制

9本のニュースを日本企業の実務に落とすと、論点は4つに整理できます。以下は本記事の報道内容を踏まえた、当社としての提案です。

1. 最上位モデルを既定にせず、タスクを必要な能力で分類してからモデルを割り当てる

最大44%は条件つきの見込みですが、高性能モデルへの過度な依存という課題は多くの企業に当てはまると考えます。使い分けは次の順で進めることを勧めます。

• 利用量の多いタスクを洗い出す：議事録の要約、問い合わせの分類、文書の下書きなど、AIに任せているタスクを書き出し、利用量の多い順に並べる
• 必要な能力で分類する：正解の形がはっきりしていて人が確かめやすいタスクと、誤りの影響が大きく高度な推論が要るタスクに分け、前者を軽量なモデルの候補にする
• 同じ入力で比べる：過去の実例を集め、高性能モデルと軽量なモデルに同じ入力を与えて、品質と手直しの時間を比べる
• 引き上げのルールを決める：軽量なモデルの結果が基準を満たさない場合に、どの条件で上位モデルに切り替えるかを決めておく

大切なのは、使い分けの判断を利用者一人ひとりに委ねず、タスクとモデルの対応を組織として決め、既定の設定に反映することです。

2. AIのコストを「1人当たり」だけでなく「1タスク当たり」で測る

LayerXの社員1人当たり月平均30万円は、支出の規模感をつかむ目安になりました。一方で、使い分けや乗り換えを判断するには、どのタスクにいくらかかっているかが分からなければなりません。

• タスクの単位で記録する：トークン消費量とコストを、利用者や部署だけでなく、タスクの種類ごとに集計できるようにする
• 手直しの時間も含める：AIの利用料だけでなく、結果を人が確かめて直した時間も、1件当たりのコストとして記録する
• 値下げの見出しで予算を組まない：モデルの価格が変わったときは、自社のタスクを実際に流して1件当たりのコストを測り直してから判断する
• 急な増加を兆候として見る：トークン消費量が急に増えたら、使い過ぎと想定外の動きの両方を疑う

1タスク当たりのコストが分かれば、使い分けの効果も価格競争の恩恵も、自社の数字で確かめられます。

3. AIエージェントが持つ認証情報をすべて棚卸しし、アクセスだけでなくふるまいを統制する

JBCCの事例を紹介した記事が指摘するとおり、管理されないまま放置された非人間IDはサイバー攻撃の脆弱性になり得ます。次の点を運用の決まりにしておくことを勧めます。

• 認証情報の棚卸し：AIエージェントや連携ツールが持つAPIキー、サービスアカウント、アクセストークンをすべて一覧にする
• 持ち主と目的を決める：1件ごとに担当者、目的、アクセスできる範囲、有効期限を記録し、目的の分からないものは止める
• 許可する操作を先に書き下す：エージェントごとに、読んでよいもの、書き込んでよいもの、外部に送ってよいものを事前に定義し、その外に出る操作を例外として扱う
• ふるまいを記録して見返す：どのIDで、どのシステムに、何をしたかを記録し、担当者が定期的に確認する

IDの棚卸しとふるまいの統制を別々の取り組みにせず、同じ一覧の上で管理することが、エージェントが増えても統制を保つ土台になります。

4. IaC×AIでは、コードを書く作業をAIに任せ、レビューと意思決定を人に残す

IaCとAIの組み合わせは人材不足への有力な選択肢ですが、記事が指摘するAI任せの限界と、脱メインフレームで指摘された生成AIへの過信を踏まえ、役割の分け方を先に決めておく必要があります。

• AIに任せる範囲を決める：構成のコード化や既存設定の書き起こしはAIに任せ、本番環境への反映は人の承認を経てから行う
• 差分でレビューする：AIが書いたコードは、変更前後の差分を人が確かめてから反映する
• 判断する人を決める：構成の方針や移行の順序など、意思決定を担う担当者を明確にする
• レビューできる人を育てる：AIの導入と並行して、インフラの構成を読み解ける人を育てる計画を持つ

AIがコードを書く速度が上がるほど、レビューの量も増えます。レビューが形式的な承認にならない量と体制を保つことが、IaC×AIを人材不足の解決策として機能させる条件です。

まとめ：AIを「使う」段階から、コストと権限を「管理する」段階へ

2026年9月26〜27日のAIニュースは、世界3本・日本6本の計9本でした。最大の話題は、高性能AIモデルへの過度な依存によるトークンコストの増大と、タスクに応じてモデルを使い分けることでコストを最大44%抑制できる可能性があるとの分析です。分析の主体や算出方法、比較の基準は要約では示されておらず、44%は条件つきの上限の見込みとして読むべき数字です。

AIエージェントの統制では、AIエージェントやAPIに割り当てられる非人間IDを統制するJBCCの実践と、AIエージェント自体のふるまいを制御するガバナンスが必要だとするAkamaiのレポートが続きました。価格の面では、Claudeの追い上げとオープンソースモデルの台頭を受けて、コスト半減のGPT-6をめぐる価格競争の激化が報じられ、週末の振り返りではGPT-6 Sol・LunaのAPI価格が前世代のプロモーション価格からさらに50%引き下げられたとされています。ほかにも、脱VMwareで顕在化したITインフラ人材不足とIaC×AI、AIによる保険コーディングが医療支出を押し上げているとの保険団体の指摘、GeminiとAIモードからFlipkartで買い物をするテスト、デジタルアバターが報じられました。

44%という数字も、GPT-6の値下げ幅も、自社のタスクに当てはめて測り直すまでは他社の条件での数字にすぎません。9本に共通しているのは、AIを使い始めた後の管理です。どのタスクにどのモデルを使うか。1タスク当たりいくらかかっているか。AIエージェントがどのIDで、何をしているか。AIが書いたものを誰が確かめ、誰が決めるか。どれも、新しいモデルや機能の登場を待たずに、今日から着手できることです。