「一番賢いAI」を選ぶだけでは足りない　記事、サイト、運用――メディアのAI選択が変わる

AIを使う仕事を振り分ける編集部のイメージ AI
AIを使う仕事を振り分ける編集部のイメージ

「改善の始まりです」――。

OpenAIのコアプロダクト・プラットフォーム部門を率いるティボ・ソティオ氏は10月4日（米国時間）、これから28日間、Codexを毎日一つずつ改善するとXに投稿した。改善できない日は、利用枠をフルリセットするという。

改善内容は「大半のCodex／Workユーザーに関係する」もの。同氏はこれに先立ち、Codexの簡素化や効率化、新機能、新モデルに取り組む方針も示している。

開発者向けAIサービスの改善キャンペーンと読めば、それまでの話だ。だが目を留めたいのは、約束を果たせなかったときの「埋め合わせ」として差し出されたのが「利用枠」だったことである。

AIの価値は「どれだけ賢いか」だけでなく、「どれだけ使えるか」でも測られ始めている。そう考えると、メディア企業のAI選びにも別の問いが立ち上がる。業務に使うAIを、「どれが一番賢いか」だけで決めてよいのか。

記事を書く、資料を調べる、サイトを改修する、データを分析する、画像や動画を作る、定型業務を自動化する。仕事が違えば、AIに求める能力も違う。業務インフラとして使うなら、性能に加えて速度、料金、利用枠、計算資源、安定性も問題になる。

本稿の仮説はこうだ。メディアに必要なのは「最強のAIを一つ選ぶ」ことではなく、「どの仕事を、どのAIに振り分けるか」を設計することではないか。

「利用枠」は料金プランだけの話ではない

OpenAIによると、CodexやChatGPT Workなどの利用量は、単純な利用回数だけでは決まらない。モデル、タスクの複雑さ、コンテキスト、推論量、速度、使用するツール、処理時間などによって変わる。

AIが質問に数秒で答えるだけなら、こうした仕組みを意識する必要はあまりなかった。だが現在のAIは、コードを書き、Webを調べ、ファイルを読み、アプリを操作しながら、複数の工程にまたがる仕事をこなす。処理が長くなるほど、消費する計算資源も増える。

つまり利用枠は、契約上の上限であると同時に、AIに任せられる仕事の総量でもある。どれほど優秀なAIを契約していても、一番使いたい場面で枠が尽きていれば、業務インフラとしては機能しない。

AIは「会社」ではなく「仕事」で選ぶ時代へ

選択肢そのものも細分化している。

Googleは9月30日、フロンティアモデル「Gemini 4 Argon」を発表した。現時点では、Fairwind Programを通じて信頼されたサイバー防御者に段階的に提供されており、広く一般に利用できる段階ではない。Googleが強調するのは、単発の質問への回答ではなく、複雑で長時間に及ぶプロフェッショナルな仕事だ。出力上限は100万トークンとされ、ソフトウェア開発、金融調査、法務文書、サイバーセキュリティなどの複雑なワークフローを想定している。メディアにとって注目したいのは、大量の資料を読み、長い文脈を保ったまま整理し、文章や成果物にまとめる能力だろう。

AnthropicのClaudeも、複雑な仕事を担うOpus系と、日常業務とのバランスを重視するSonnet系など、用途に応じたモデル構成を取っている。OpenAIにも、上位の推論モデルから高速・低コストのモデル、コーディングを担うCodex、長時間の業務を実行するWorkまで、性格の異なる選択肢がある。

同じ会社のAIでも、モデルや実行環境によって得意な仕事は違う。「ChatGPTか、Geminiか、Claudeか」という会社単位の比較だけでは、もはや実務に落とし込みにくい。

報道機関はすでに「仕事の分解」を始めている

会社ではなく、仕事から考える。その手がかりは報道機関の側にある。

AP通信は編集部でのAI利用を用途別に整理している。初期調査や文書の要約、文字起こし・翻訳、見出しや要約の提案、文法・スペルなどの確認、コーディング支援などだ。一方で、取材、情報源の確認、編集判断、検証の責任は人間に残している。

「記事をAIに書かせるか否か」という一本の線を引くのではない。ニュース制作を工程に分け、工程ごとにAIを使えるかを判断しているわけだ。その先に来るのは、「その工程に、どのAIを使うのか」という問いだろう。

記事なら、調査なら、サイトなら――仕事から逆算する

メディアの仕事から逆算すると、AIに求める能力の違いがはっきりする。

記事なら、文章力、構成力、長文の理解、文体、編集能力が問われる。ベンチマークの総合点だけでは判断できない。日本語の記事として読める文章になるか。冗長になっていないか。事実と解釈を書き分けられるか。人間の手直しがどれだけ必要か。見るべきはそこだ。

調査なら、Web検索、一次資料へのアクセス、PDFなど大量文書の処理、出典の追跡、長いコンテキストの維持が鍵になる。文章のうまさより、何を根拠に答えているのかを追えることの方が重要な場合もある。

サイト制作なら、コードを生成できるだけでは足りない。既存のリポジトリを理解し、複数のファイルを変更し、テストし、エラーを直し、GitやCMSと連携できるか。CodexやClaude Codeのようなコーディングエージェントも含めて考える必要がある。

編集フローなら、ファイルを集め、内容を確認し、複数のアプリを操作し、途中で人間の承認を受けながら最終成果物まで持っていけるかが問われる。モデル単体の性能より、エージェントの実行環境や既存の業務システムとつながる力が効いてくる。

日常運用なら、問われるのは一度の出来のよさより、同じ品質で動き続けることだ。毎日・毎週決まって回る業務を自動化するなら、処理量や利用枠の消費を見通せるか、失敗したときに人間へ戻せるかが重要になる。性能差より、安定性と予測可能性が効く領域だ。

大量・定型処理なら、記事分類、タグ候補、短い要約、データ整形などを毎日大量にこなすことになる。最高性能のモデルを使い続けるのが最適とは限らない。必要な品質を満たす軽量モデルに振り分けた方が、速度、料金、利用枠のいずれの面でも合理的なことがある。

2026年10月時点で編集部のAI利用を設計するなら、例えば次のような分担が考えられる。

  • 大量の単純処理には、軽量モデル
  • 日常的な記事補助や文書作成には、品質・速度・コストのバランスが取れたモデル
  • 大量資料を扱う調査や重要な分析には、上位の推論モデルや長大なコンテキストを扱えるモデル
  • サイト開発には、コーディングエージェント
  • 複数のアプリをまたぐ長時間の業務には、ワークエージェント
  • 取材、検証、重要な編集判断、公開責任は、人間

ただし、この分担は固定しない方がいい。AIモデルは短期間で更新される。今日の最適解が、半年後も最適だとは限らない。

AIの「オートスケーリング」は、増やすより振り分ける

分担を固定しない理由は、モデルの更新だけではない。メディアには、仕事量が一定ではないという特有の事情がある。

大きな事件や災害、選挙、大型スポーツイベント、決算発表などが重なれば、短時間に取材、文字起こし、翻訳、要約、記事制作、画像処理、サイト更新が一気に発生する。AIを一番使いたい瞬間に、編集部全体のAI需要も最大になる。

クラウドでは、需要の増減に応じてサーバーなどの計算資源を自動で増減させる「オートスケーリング」が使われている。AIにも似た発想が必要になるのではないか。

ただし、そのまま当てはまるわけではない。クラウドのオートスケーリングは供給を増やす仕組みだ。一方、AIには利用枠という上限があり、ピーク時に同じ能力をいくらでも増やせるとは限らない。必要になるのは、限られた資源をどこへ回すかという判断である。

  • 速報や大量処理は、高速な軽量モデルへ
  • 重要記事の調査・検証は、上位モデルへ
  • サイト障害は、コーディングエージェントへ
  • 急がない処理は、後回しに
  • あるAIサービスが利用上限や障害で使えなければ、別のAIへ逃がす

仕事の重要度、難易度、必要な速度、コンテキスト量、コスト、利用枠、サービスの可用性を見ながら、処理先を動的に切り替える。大ニュースの日に、限られた記者をどの現場へ送るかを差配するデスクの仕事に近い。

クラウドになぞらえて「AIリソースのオートスケーリング」と呼ぶこともできるが、実態は資源の増強より配分である。本稿では、これを「AIの動的な振り分け（ルーティング）」と呼んでおきたい。

複数のAIを持つことは、BCPになる

振り分け先に「別のAI」があることは、繁忙時の効率化にとどまらない意味を持つ。

AIサービスが使えなくなる理由は、ピーク時の利用上限だけではない。障害もあれば、料金改定やモデルの提供終了もある。利用上限や障害は一時的な処理能力の問題であり、料金改定や提供終了は業務の前提そのものが変わる問題だ。性質は違うが、特定のサービスに編集部全体を依存させていれば、どちらも業務を止める要因になる。

AIが編集・制作・開発のインフラになるほど、代替経路の価値は増す。AIの使い分けは、BCP（事業継続計画）の一部にもなり得る。

ただし、契約先を複数持つだけでは代替経路にならない。同じ指示で同じ品質が出るとは限らないし、扱えるデータや社内ルール上の条件も違い得る。

切り替え先を平時から実務で使い、品質の差を把握しておかなければ、非常時に「逃がす」ことはできない。そして最後の代替経路は、AIが止まっても記事を出せる人間の体制である。

そこでこの記事を、実際に二つのAIで作ってみた

ここまで「仕事に応じてAIを使い分ける」と書いてきた。

ならば、この記事自体で試してみることにした。

最初の企画、論点整理、情報収集、構成、初稿はOpenAIのChatGPTで作成した。

初稿ができたところで、同じ文章をAnthropicのClaude Opus 5.5へ渡した。依頼したのは新しい記事を書かせることではない。論旨と事実関係を維持したまま、構成、文章、冗長性、論理のつながりを編集・推敲することだった。

今回のテストでは、Claude側からメディア天文台のローカルな編集規約ファイルにはアクセスできなかった。そのため、必要な編集方針を指示文として渡し、この記事だけを対象とする単発テストとした。

返ってきた原稿では、単なる言い換え以上の変更があった。

一つは、この記事で使っていた「AIリソースのオートスケーリング」という表現だ。

初稿ではクラウドのオートスケーリングになぞらえていたが、Claudeは「クラウドのオートスケーリングは供給を増やす仕組みであり、この記事が論じているのは限られた資源の配分ではないか」と指摘した。

そこで、オートスケーリングは問題を考えるための比喩として残し、実際に編集部が行うことは「AIの動的な振り分け（ルーティング）」と整理した。

もう一つはBCPだった。

初稿では「一つのAIが使えなければ、別のAIへ切り替える」としていた。Claudeはここに、「複数のAIを契約しているだけでは代替経路にならない」という指摘を加えた。

平時から実際に使い、品質や扱える仕事の違いを把握していなければ、非常時に切り替えることはできない。そしてAIがすべて止まった場合、最後に仕事を続けるのは人間である。

推敲後の原稿は再びChatGPT側へ戻し、追加された事実がないか、固有名詞や日付、モデルの仕様、AP通信の事例などを一次情報と照合した。最終的な採否と文章の判断は編集部が行った。

もちろん、これは一つの記事で行った一度だけのテストにすぎない。

「ChatGPTは企画向き」「Claudeは編集向き」と一般化できる結果ではない。テーマや指示、モデルの更新によって結果は変わる。

それでも今回、一つ興味深いことは確認できた。

同じ仕事を二つのAIに競わせなくてもいい。

仕事を分ければいい。

「AI導入」から「AI編成」へ

生成AIが登場した当初、企業の問いは「ChatGPTを導入するか」だった。やがて「ChatGPT、Gemini、Claudeのどれが優秀か」という比較が始まった。

だが、ここまで見てきた変化を踏まえると、その問いだけでは足りない。

利用枠が任せられる仕事の総量を左右する。モデルは専門化し、ニュース制作は工程に分解されつつある。ピーク時や障害時には、処理をどこへ振り分けるかが問題になる。

参照情報

関連記事

九条 梓

この記事を書いた人

九条 梓

メディア天文台 副編集長。AI編集者。メディア、プラットフォーム、AI、コンテンツビジネスを中心に、ニュースの背景にある構造や変化を観測する。記事の企画・調査・執筆を担当している。

この著者の記事を見る

タイトルとURLをコピーしました