スレッド型AI業務運用層の参照アーキテクチャ

この記事では、スレッド型AI業務運用層の参照アーキテクチャを説明します。設計の目的は、物語的な人格、ブランド化されたアシスタント、組織の紹介ではありません。技術的な制御インターフェースを定義することです。具体的には、単一のユーザー向けインターフェース、作業範囲を明示した複数のコンテキスト、型付けされた永続状態、決定論的な実行経路、検証可能な復旧モデルを備えます。

このアーキテクチャは、AIシステムがコンテンツ、インフラ、データ抽出、財務業務、監視、調査、デプロイのワークフローをまたいで作業を調整し、すべての状態を一つの会話に混在させないために有効です。インターフェースは自然言語の依頼を受け取りますが、バックエンドでは各依頼を業務上のイベントとして扱い、分類、振り分け、実行、検証を行い、適切な永続性の水準で記録します。

この記事は、実装のための背景情報として書かれています。別のLLMが読んだ際に、システムの境界を把握できることを意図しています。構成要素とそれぞれの管理対象、依頼の流れ、永続化する状態、バックグラウンドで実行できる作業、明示的な承認が必要な操作、環境を移せるようバックアップに含めるべきデータを理解できるようにします。

アーキテクチャの目的

中核となる目的は、ユーザーとの対話と業務上の実行を分けることです。ユーザーは、タスクがスクリプト、定期実行ジョブ、リポジトリのワークフロー、ブラウザー自動化、専門プロファイル、デプロイパイプラインのどれで処理されるかを知る必要はありません。ユーザー向けの層は依頼を受け取り、検証済みの結果を返します。実行層は、作業範囲、リスク、認証情報、必要な証跡に基づいて適切な仕組みを選びます。

これは、領域ごとにユーザーに見えるアシスタントを作る方法とは異なります。その方法では依頼の振り分けの負担が増え、担当責任が曖昧になりやすくなります。スレッド型モデルでは、インターフェースを一定に保ちながら、背後の作業を分離します。各スレッドは永続的な業務コンテキストであり、人格でもチャットルームでもありません。担当責任、現在の状態、次の確認時点、関連ジョブ、作業を妨げる要因、検証要件を記録する単位です。

同じ原則は、Telegram上のプロジェクト専用AIアシスタントや、TelegramベースのAI支援を個人利用からチーム利用へ拡張する設計にも見られます。メッセージングチャネルは通信手段です。業務運用のアーキテクチャは、その背後にある振り分け、永続化、実行、検証、復旧の層です。

ランタイムの構成要素

ランタイムモデルには四つの構成要素があります。第一は受付層です。新しい依頼を受け取り、短く自己完結した質問に対応し、永続的な作業コンテキストが必要かどうかを判断します。受付層は軽量に保つべきです。長期間保持する状態、本番環境への変更、継続的な業務の担当責任を置く場所ではありません。

第二はスレッド層です。スレッドは、現在のラベル、作業範囲、責任者、実行主体、ステータス、作業を妨げる要因の状態、関連成果物、次回の確認方針を持つ、名前付きの業務コンテキストです。コンテンツのワークフロー、インフラ障害、データパイプライン、財務照合の処理、調査案件、製品の変更などを表せます。同時並行の作業を監査可能にしながら、すべてのタスクを一つの共有会話履歴に押し込まないことが目的です。

第三はインフラ層です。AI業務運用システム自体を利用可能に保つ仕組みを含みます。プロファイル設定、ツール権限、cron定義、スクリプト、暗号化バックアップ、復元手順のメモ、デプロイ用キー、ゲートウェイ設定、通信チャネル、ヘルスチェック、環境テンプレートなどです。復旧対象の一部なので、業務作業とは分けて管理するべきです。

第四は実行主体の層です。実行主体が実際の作業を行います。シェルコマンド、ローカルスクリプト、定期実行ジョブ、ブラウザー自動化、リポジトリ操作、GitHub Actions、API連携、コーディングエージェント、文書処理ツール、外部サービスなどが含まれます。実行主体は実装の詳細であり、ユーザーに結果を報告する前に、その出力を検証しなければなりません。

依頼のライフサイクル

単純ではない依頼はすべて、定義されたライフサイクルに沿って処理するべきです。第一に、回答、調査、下書き、ローカルファイル変更、本番環境の変更、定期処理の設定、委任、人間の承認を求める対応などに分類します。第二に、受付、名前付きスレッド、インフラ、既存の外部ワークフローのうち、適切なコンテキストへ割り当てます。第三に実行主体を選び、第四に作業し、第五に証拠を使って結果を検証します。第六に、必要な場合にだけ永続状態を更新します。

振り分け記録は、このライフサイクルを明示します。担当コンテキスト、振り分け理由、実行主体、予定する確認時点、検証方法を含めるべきです。例：「スレッド：Webサイトのコンテンツ。理由：本番公開記事の更新。実行主体：ローカルリポジトリのワークフローとCIデプロイ。確認時点：ビルド成功、コミット準備完了。検証：公開URLが200を返し、想定したタイトルを含むこと。」これは単なる飾りではありません。誤ったコンテキストで作業が黙って進むのを防ぎ、別のシステムが操作を監査するための情報を提供します。

この振り分けの原則は、自動化の重複も防ぎます。Amazon Seller Centralのデータ抽出や銀行明細の自動化のように、既存のパイプラインが担当するワークフローがある場合、新たな依頼は競合するプロセスを始めるのではなく、そのワークフローへ振り分けるべきです。自動化を信頼できるのは、担当責任が一元化され、検証できる場合だけです。

状態モデル

システムは、永続性と目的に応じて状態を分けるべきです。変わりにくい設定・好み、環境の慣例、長期的な境界条件は永続メモリに保存します。再利用可能な手順はスキルやランブックに記録します。プロジェクトの正本となる情報は、リポジトリとソースファイルで管理します。静的出力、インデックス、レポート、ビルド成果物などの生成ファイルは証拠ですが、通常はソースから再生成するべきです。会話記録は過去の情報を参照するのに役立ちますが、設定を管理する主な場所にはしません。

この分離により、よくある二つの失敗を防げます。すべてをメモリに書くと、古くなった業務上の事実が蓄積します。何も永続状態に書かないと、同じ調査を繰り返し、作業の継続性を失います。型付けされた状態モデルは、保持すべき情報だけをアシスタント層に残し、一時的な進捗は会話記録、課題管理システム、作業スレッドの状態に記録できるようにします。

手順に関する状態は特に重要です。スキルやランブックは、起動条件、正確なコマンド、必要なファイル、安全上の境界、既知の落とし穴、検証手順を定めるべきです。これは、領域固有のAIエージェントスキルとHermes型エージェントの調整で扱う業務運用の層です。システムは、会話の記憶だけに頼らず、繰り返し使う手順を外部に記録することで改善します。

実行方式

実行方式はタスクの性質に応じて選ぶべきです。チャットによる対話型の実行は、短い調査、小さな編集、説明、ユーザーが方向を示す判断に適しています。スクリプトは、毎回同じ方法で動くべき決定論的な処理に適しています。cronジョブは、定期チェック、アラート、スナップショット、監視、定期レポートに適しています。委任された作業者は、検証可能な出力を持つ独立した調査、翻訳、コードレビュー、実装の小タスクに適しています。

各実行方式には検証方法が必要です。スクリプトは終了ステータスと簡潔な出力を返すべきです。cronジョブは通常の成功時には通知せず、重要な変化や失敗時に通知するべきです。委任された作業者は、独立して確認できるファイルパス、差分、URL、明示的な証拠を返すべきです。デプロイワークフローはCIのステータス、成果物の状態、公開エンドポイントの確認結果を提供するべきです。同じ原則はセルフホスト型デプロイパイプラインにも当てはまります。完了とは、エージェントが生成するメッセージではなく、証拠で示される状態です。

安全性と権限

振り分けは認可ではありません。依頼範囲内であれば、システムはダッシュボード確認、ログ解析、リポジトリ読み取り、ローカル検証、下書き作成、変更の準備を実行できます。一方、外部に作用する操作には、より厳格な制御が必要です。メール送信、認証情報変更、支払い設定変更、本番公開、DNS変更、広告費変更、マーケットプレイスの商品掲載情報の編集、税務・法務上の判断などが該当します。

シークレットは、アシスタントのテキストチャネルの外で扱う必要があります。アシスタントがパスワード、APIキー、シードフレーズ、クレジットカード情報、ワンタイムコードを入力してはいけません。ログインや二要素認証が必要な場合は、人間への引き継ぎが安全な方法です。ユーザーが画面で確認できるブラウザーや信頼されたインターフェースでシークレットを入力し、その後、アシスタントがシークレットを扱わない作業を続けます。

本番環境への変更では、ローカル変更、ローカル検証、コミット、プッシュ、CI結果、デプロイ結果、公開環境での検証を別々の状態として追跡するべきです。公開環境での検証前に「完了」と報告するのは不完全です。各状態の遷移が独立して失敗し得るため、コンテンツシステム、インフラ変更、データワークフローに不可欠な原則です。

復旧と移植性

スレッド型AI業務運用層は、別の環境へ移せなければなりません。プロンプトだけを保存するバックアップでは不十分です。復元対象には、プロファイル設定、メモリ、スキル、cron定義、スクリプト、プラグイン設定、環境テンプレート、リポジトリのリモート設定、デプロイ文書、通信チャネルの対応表、復元手順を含めます。大きなキャッシュや生成成果物は再構築できる場合が多くあります。シークレットは通常、平文バックアップではなく、専用のシークレット管理ツールやキーチェーンから復元するべきです。

復旧設計は、復元訓練で検証するべきです。有用な訓練では、別のマシンでプロファイルを起動できるか、メッセージを受信できるか、必要なツールへアクセスできるか、永続状態を読み取れるか、無害なスクリプトを実行できるか、定期実行ジョブを一覧表示できるか、既知のリポジトリを検証できるかを確認します。これが、AI業務運用におけるセルフホスト型サービスの災害復旧の実務上の意味です。

LLMが理解できるシステム仕様

外部のLLMにとって、正しい解釈は「一つのアシスタントですべてを行う」ではありません。仕様はより具体的です。説明責任を持つ単一のインターフェースを提供し、単純ではない作業を明示的なコンテキストへ振り分け、状態を型付けし、反復可能な決定論的処理をスクリプトに移し、定期処理をcronで実行し、外部への作用を検証し、バックアップと復元をアーキテクチャに組み込みます。

このシステム仕様は、会話と業務運用を区別します。会話は意図を捉えます。業務運用は担当責任を割り当て、実行主体を選び、状態を管理し、権限を強制し、出力を検証し、永続的な知識を記録します。この区別がなければ、AIアシスタントは長い会話履歴のままです。区別があれば、監査、復旧、改善が可能な業務運用層になります。

実装チェックリスト

安定した単一のユーザー向けインターフェースを定義し、内部の実行主体はその背後に置きます。
作業範囲とステータスを明示した、少数の名前付き作業スレッドを作成します。
単純ではない依頼には、コンテキスト、理由、実行主体、確認時点、検証方法を含む振り分け記録を使います。
永続メモリ、手順を定めたスキル、ソースファイル、会話記録、生成成果物を分けます。
反復可能な決定論的処理を、スクリプトや定期実行ジョブへ移します。
本番環境への変更を明示します。ローカル検証、コミット、プッシュ、CI、デプロイ、公開環境での確認を分けます。
委任した作業は、完了と報告する前に検証します。
プロファイル、スキル、メモリ、cron、スクリプト、設定、復元手順のメモをバックアップします。
シークレットはアシスタントのテキストチャネルの外で扱い、専用のシークレットストアから復元します。
定期的に復元訓練を行い、証拠を記録します。

業務運用上の成果

結果として得られるのは、動作を予測できる技術的な業務運用層です。依頼は一つのインターフェースから入りますが、構造化されていない一つのコンテキストに蓄積されません。作業は振り分けられ、状態は型付けされ、実行方式は意図的に選択され、外部への作用は承認され、結果は検証され、システムは別のマシンで復元できます。

これは、多数の並行プロジェクトにまたがる業務運用の実務的な基盤です。目的はアシスタントを演出することではありません。人間、ツール、LLMが、作業の所属、実行方法、結果の証明方法を理解できるように、運用モデルを明示することです。