【ITニュース解説】From Claude Project to Hybrid AI Agent: Lessons from a Real-World Content Workflow

このニュース記事は、AI（人工知能）を実世界の課題に適用する際に、完全な自動化を目指すのではなく、人間、AI、従来のソフトウェアのそれぞれの強みを組み合わせた「ハイブリッドAIエージェント」が非常に有効であるという重要な教訓を伝えている。システムエンジニアを目指す皆さんにとって、実用的なシステム設計の考え方を学ぶ上で非常に参考になるだろう。

記事の筆者は、教会の日常的な精神的なメッセージを中国語から英語に翻訳し、公開するという作業の効率化からこのプロジェクトを始めた。最初は単に繰り返しの翻訳作業を減らしたいという目的だったが、試行錯誤するうちに、これはAIエージェントのようなワークフローになっていることに気づいた。具体的には、大規模言語モデル（LLM）であるClaudeが言語と推論（考える部分）を担当し、Pythonのような従来のプログラムが決められた処理（ファイルを変換する部分）を担当し、そして人間が最終的な確認と公開（判断する部分）を行うという構成だ。ここで最も驚くべき発見は、必ずしも「完全に自動化する」ことが最終目標ではないということだった。

筆者が直面した具体的な問題は、毎週6日分の中国語メッセージ（PowerPointやPDF形式）から、バイリンガル版と英語のウェブサイト版を作成することだった。一見すると単純な翻訳に見えるが、実はそうではない。元原稿には日付、曜日、見出し、聖書引用、祈り、賛美歌など、さまざまな要素が含まれており、それぞれに異なる処理が必要となる。例えば、聖書引用は単に中国語から直訳するのではなく、特定の英語聖書（NASB 2020）から引用する必要があり、賛美歌は翻訳せずそのまま残す必要がある。また、小見出しや祈りの構造も維持しなければならない。

そこで、最初のLLMへの指示（プロンプト）は、単なる「翻訳してください」という簡単なものではなく、詳細な仕様書のようなものへと進化した。特定の用語を使う、聖書引用は特定のバージョンを使う、賛美歌は翻訳しない、小見出しは太字のMarkdown形式で維持する、そして、最終的な出力は各日ごとにJSON形式で、タイトルと内容のフィールドのみを生成するという具体的な指示だ。

これにより、LLMは単に文章を生成するだけでなく、まるで「インターフェース契約」を結んだかのように、決められた構造のデータを出力するようになった。この「構造化された出力」が極めて重要だった。なぜなら、次にそのデータを受け取るのが従来のソフトウェアだからだ。

LLMが生成したJSONデータを受け取った後、筆者はPythonプログラムを使って、英語のコンテンツをPowerPointの英語テンプレートに挿入する処理を行った。ここで明らかになったのは、「すべてをLLMに任せるべきではない」という原則だ。英語の翻訳には言語の理解や文脈判断が必要であり、これはLLMが得意とするところだ。しかし、特定の文字列をPowerPointの特定のテキストボックスに挿入するという作業は、決まった手順に従うだけであり、推測や判断は一切不要だ。このような「決定的」な作業は、Pythonのような従来のプログラムに任せるのが最適で、LLMにやらせる必要はない。

Pythonプログラムは、月曜日の内容はスライド1へ、火曜日の内容はスライド2へといった対応関係を認識し、タイトルと内容を挿入してPowerPointファイルを生成する。しかし、この時点でも人間の確認は不可欠だった。なぜなら、PowerPointの書式設定は視覚的なものだからだ。技術的にはテキストがテキストボックスに収まっていても、見た目が悪かったり、改ページが不自然だったり、フォントの調整が必要だったりする。コンピュータはテキストが挿入されたかどうかは判断できるが、スライドが「見た目良く」できているかどうかは人間が判断しなければならない。これが「決定的自動化」と「人間の判断」との境界線である。

さらに、英語のPowerPointが確認された後、別の自動化ステップで、それを中国語のPowerPointと結合する。最終的なプレゼンテーションには、日付ごとに中国語6日分と英語6日分の合計12日分のメッセージが並ぶ。この結合作業も、LLMに推論させる必要はない。例えば、「2026年4月28日に対応する中国語スライドはどれか？」という問いに対し、答えは日付によって明確に決まるため、これも従来のプログラムで処理できる。

このようにして、このワークフローは異なる種類の「スキル」の集合体として捉えられるようになった。LLMは翻訳、文脈解釈、用語選択、コンテンツ構造化、意味的書式設定といった「推論スキル」を、従来のソフトウェアはJSON解析、PowerPoint生成、日付照合、スライド結合、HTML生成といった「決定的スキル」を、そして人間は翻訳や神学的レビュー、視覚的な品質管理、最終公開承認といった「判断スキル」を担当する。つまり、「エージェント」とは単一のAIモデルではなく、これらの異なる能力を連携させる「オーケストレーション（統合・調整）」されたシステムなのだ。

このプロジェクトを通じて筆者は、一連の自動化スクリプトとしてではなく、全体を統括する「オーケストレーター」を持つシステムとして考えるようになった。オーケストレーターの役割は、すべてのタスクを自分で行うのではなく、全体の目標と制約を理解し、ワークフローを分解し、各タスクを適切な能力（LLM、ソフトウェア、人間）に振り分けることである。そして、中間出力を監視し、次のステップに進む準備ができているかを検証し、判断が必要な場合には人間にエスカレートして処理を停止させる。この「制御された自律性」によって、システムは予測可能なことは自動化し、判断が重要な場面では一時停止して人間の介入を求める。

なぜ完全な自動化を目指さなかったのか、という問いに対し、筆者は「信頼性」を挙げている。個々のステップは技術的に自動化できても、チェーン全体の信頼性を確保するのは難しい。例えば、翻訳は文法的に正しくても文脈にそぐわない場合があり、聖書引用はほぼ正確でも求められるバージョンと完全に一致しないかもしれない。JSONの出力に予期せぬ書式設定の問題が含まれる可能性や、PowerPointが構造的には正しくても見た目が悪い場合もある。最終的にウェブサイトに公開される場合、「だいたい合っている」では不十分なのだ。

この経験から得られた教訓は、システムエンジニアを目指す上で非常に重要だ。 第一に、「エージェント」から始めるのではなく、「ワークフロー」から始めるべきだ。まず実際のワークフローがどうなっているのか、そのどの部分に「知能」（判断力）が必要なのかを見極めることで、LLMをどこに配置すべきかが明確になる。 第二に、推論と決定的処理を分離する。予測可能な入力と出力を持つタスクには従来のソフトウェアが適しており、言語理解や文脈解釈、曖昧さの処理が必要なタスクにはLLMが適している。それぞれの得意分野を理解し、役割を明確に分けることが、システムを不必要に複雑にせず、信頼性を高める鍵だ。 第三に、プロンプトを「インターフェース」として扱う。LLMへの指示は単なる命令ではなく、後続のシステムが利用できるような構造化された出力（例：JSON）を期待する「契約」として設計する。これにより、LLMの推論結果が明確な形で次の決定論的ソフトウェアに渡され、全体のワークフローのテストや自動化が容易になる。 第四に、「人間が介在する」ことは重要な機能であると認識する。筆者は当初、最終的には人間によるレビューを排除したいと考えていたが、文脈、神学、視覚的な品質、そして公開に関する判断が必要なコンテンツにおいては、人間によるレビューが品質と説明責任を保証する重要なレイヤーであると理解した。目標は人間をなくすことではなく、人間の関与をより集中させ、価値あるものにすることだ。 最後に、最高のAIエージェントは「ハイブリッド」である。LLM、決定的コード、人間の判断というそれぞれの強みを組み合わせることで、機械が苦手な言語と意味の処理をLLMが、LLMに任せるべきではない予測可能な変換をコードが、そしてまだ判断と責任を必要とする部分を人間が担当する。

このプロジェクトは、週ごとの教会のメッセージ翻訳という具体的な課題から始まり、最終的にはAIエージェント設計における予想外の実験となった。完全に自律的なエージェントは完成しなかったが、より実用的で有用なものが生まれた。それは、各能力が明確な役割を持つハイブリッドAIワークフローである。最も重要な教訓は、「AIエージェントの目標は常に人間をワークフローから排除することではない。人間にとって不要な労力を取り除きつつ、重要な判断が求められる場面では人間の判断を維持することを目指すべきだ」ということだ。現実世界のAIシステムにおいては、エージェントがいかに自律的に見えるかよりも、この区別を理解することがはるかに重要である。本当に賢いエージェントとは、何を自動化できるか、何をソフトウェアに任せるべきか、そしていつ停止して人間に助けを求めるべきかを知っているシステムなのである。