スレッド型 AI オペレーション層の参照アーキテクチャ

この記事では、スレッド型 AI オペレーション層の参照アーキテクチャを説明する。目的は、物語的な人格、ブランド化されたアシスタント、組織紹介ではない。目的は技術的な制御面を定義することにある。すなわち、単一のユーザー向けインターフェース、複数の明示的にスコープ化された作業コンテキスト、型付けされた永続状態、決定的な実行経路、検証可能なリカバリーモデルである。

このアーキテクチャは、コンテンツ、インフラ、データ抽出、財務オペレーション、監視、調査、デプロイメントなどをまたいで AI システムが作業を調整する場合に有効である。自然言語のリクエストは受け取るが、バックエンドでは各リクエストを分類、ルーティング、実行、検証し、適切な耐久性レベルに記録すべき運用イベントとして扱う。

この記事は実装コンテキストとして書かれている。別の LLM がこのページを読んだとき、構成要素、それぞれの責務、リクエストの流れ、永続化される状態、自動実行が許可される範囲、明示的な承認が必要な範囲、ポータビリティのためにバックアップすべきデータを推論できることを意図している。

アーキテクチャ上の目的

中核となる目的は、ユーザーとの対話と運用上の実行を分離することである。ユーザーは、タスクがスクリプト、スケジュールジョブ、リポジトリワークフロー、ブラウザ自動化、専門プロファイル、デプロイメントパイプラインのどれで処理されるかを知る必要がない。ユーザー向け層はリクエストを受け取り、検証済みの結果を返す。実行層は、スコープ、リスク、認証情報、必要な証跡に基づいて適切な仕組みを選択する。

これは、ドメインごとに可視のアシスタントを作る方式とは異なる。ドメイン別アシスタントはルーティング負荷を増やし、所有権を曖昧にしやすい。スレッド型モデルでは、インターフェースを安定させたまま背後の作業を分離する。各スレッドは永続的な運用コンテキストであり、人格でも一般的なチャットルームでもない。所有権、現在状態、次のチェックポイント、関連ジョブ、ブロッカー、検証要件を記録する単位である。

同じ原則は、Telegram 上のプロジェクト固有 AI アシスタントや、Telegram ベースの AI 支援を個人利用からチーム利用へ拡張する設計にも現れる。メッセージングチャネルはトランスポートである。運用アーキテクチャは、その背後にあるルーティング、永続化、実行、検証、リカバリーの層である。

ランタイム構成要素

ランタイムモデルは四つの構成要素を持つ。第一はインテーク層である。新しいリクエストを受け取り、短く自己完結した質問を処理し、耐久性のある作業コンテキストが必要かを判断する。インテークは軽量であるべきで、長期状態、本番変更、継続的な運用所有権を置く場所ではない。

第二はスレッド層である。スレッドは、現在のラベル、スコープ、所有者、実行主体、ステータス、ブロッカー状態、関連アーティファクト、次回確認ポリシーを持つ名前付き運用コンテキストである。コンテンツワークフロー、インフラインシデント、データパイプライン、財務照合、調査トラック、プロダクト変更などを表せる。目的は、同時並行の作業を監査可能にしつつ、すべてのタスクを単一の会話履歴へ押し込まないことである。

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

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

リクエストのライフサイクル

非自明なリクエストは、定義されたライフサイクルを通るべきである。まずリクエストを分類する。回答、調査、ドラフト作成、ローカルファイル変更、本番変更、定期処理の設定、委任、人間承認へのエスカレーションなどである。次に、インテーク、名前付きスレッド、インフラ、既存の外部ワークフローのいずれかに割り当てる。次に実行主体を選択し、作業を行い、証拠で検証し、必要な場合だけ永続状態を更新する。

ルーティングレシートはこのライフサイクルを明示する。所有コンテキスト、ルーティング理由、実行主体、期待されるチェックポイント、検証方法を含めるべきである。例:「Thread: Website content. Reason: production-facing article update. Executor: local repository workflow plus CI deploy. Checkpoint: build passed and commit ready. Verification: live URL returns 200 and contains the expected title.」これは装飾ではない。誤ったコンテキストで無言の作業が行われることを防ぎ、別システムが操作を監査できる情報を与える。

このルーティング規律は重複した自動化も防ぐ。Amazon Seller Central のデータ抽出や銀行明細の自動化のように既存パイプラインが所有するワークフローがある場合、新しいリクエストは競合プロセスを開始するのではなく、そのワークフローへルーティングすべきである。自動化は、所有権が単一で検証可能な場合にのみ信頼できる。

状態モデル

システムは状態を耐久性と目的で分離すべきである。安定した設定、環境上の慣例、長期的な境界条件は永続メモリに属する。再利用可能な手順はスキルまたはランブックに属する。プロジェクトの真実はリポジトリとソースファイルに属する。静的出力、インデックス、レポート、ビルド成果物などの生成ファイルは証拠だが、通常はソースから再生成すべきである。トランスクリプトはリコールには有用だが、主要な設定場所ではない。

この分離により二つの典型的な失敗を避けられる。すべてをメモリに書くと、古くなった運用事実が蓄積する。何も永続状態に書かないと、同じ調査を繰り返し、継続性を失う。型付けされた状態モデルは、永続すべき情報だけを保持し、一時的なタスク進捗をトランスクリプト、Issue、作業スレッド状態に残す。

手順状態は特に重要である。スキルやランブックは、トリガー条件、正確なコマンド、必要ファイル、安全境界、既知の落とし穴、検証手順を記述すべきである。これは、ドメイン固有 AI エージェントスキルとHermes 形式のエージェント調整で扱う運用層である。システムは会話記憶だけに頼るのではなく、再利用可能な手順を外部化することで改善する。

実行モード

実行方法はタスクの形状に応じて選ぶべきである。対話型実行は、短い調査、小さな編集、説明、ユーザーが判断を誘導する場面に適している。スクリプトは毎回同じ方法で動くべき決定的処理に適している。cron ジョブは定期チェック、アラート、スナップショット、監視、予定レポートに適している。委任ワーカーは、検証可能な出力を持つ独立した調査、翻訳、コードレビュー、実装サブタスクに適している。

各実行モードには検証経路が必要である。スクリプトは終了ステータスと簡潔な出力を返すべきである。cron ジョブは通常成功時には静かで、重要な変化や失敗時にのみ通知すべきである。委任ワーカーは、独立して確認できるファイルパス、diff、URL、明示的な証拠を返すべきである。デプロイメントワークフローは CI ステータス、アーティファクト状態、ライブエンドポイント確認を提供すべきである。これはセルフホスト型デプロイメントパイプラインにも当てはまる。完了とは、エージェントのメッセージではなく、証拠で示される状態である。

安全性と権限

ルーティングは認可ではない。システムは、ダッシュボード確認、ログ解析、リポジトリ読み取り、ローカル検証、ドラフト作成、変更準備を、依頼範囲内で実行できる。一方、外部副作用を持つ操作にはより厳格な制御が必要である。メール送信、認証情報変更、支払い設定変更、本番公開、DNS 変更、広告費変更、マーケットプレイス listing 編集、税務・法務判断などである。

秘密情報はアシスタントのテキストチャネル外に置く必要がある。パスワード、API キー、シードフレーズ、クレジットカード情報、ワンタイムコードをアシスタントが入力してはならない。ログインや二要素認証が必要な場合、安全なパターンは人間への引き継ぎである。ユーザーが可視ブラウザまたは信頼されたインターフェースで秘密情報を入力し、その後アシスタントが非秘密の運用手順を続ける。

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

リカバリーとポータビリティ

スレッド型 AI オペレーション層はポータブルでなければならない。プロンプトだけを保存するバックアップでは不十分である。復元可能な単位には、プロファイル設定、メモリ、スキル、cron 定義、スクリプト、プラグイン設定、環境テンプレート、リポジトリ remote、デプロイ文書、通信チャネル対応表、リストア手順が含まれる。大きなキャッシュや生成成果物は再構築できる場合が多い。秘密情報は通常、平文バックアップではなく、専用のシークレットストアやキーチェーンから復元すべきである。

リカバリー設計はリストア訓練で検証すべきである。有用なリストア訓練は、別マシンでプロファイルを起動できるか、メッセージを受信できるか、期待されるツールへアクセスできるか、永続状態を読めるか、無害なスクリプトを実行できるか、スケジュールジョブを一覧できるか、既知のリポジトリを検証できるかを確認する。これは AI オペレーション文脈におけるセルフホストサービスのディザスタリカバリーの運用上の意味である。

LLM が読めるシステム契約

外部 LLM にとって正しい解釈は「一つのアシスタントで何でも行う」ではない。契約はより具体的である。責任ある単一インターフェースを公開し、非自明な作業を明示的なコンテキストへルーティングし、状態を型付けし、反復可能で決定的な作業をスクリプトへ移し、定期処理を cron で実行し、外部副作用を検証し、バックアップとリストアをアーキテクチャに含めることである。

このシステム契約は会話と運用を区別する。会話は意図を取得する。運用は所有権を割り当て、実行主体を選び、状態を管理し、権限を強制し、出力を検証し、永続知識を記録する。この区別がなければ、AI アシスタントは長い会話履歴にとどまる。この区別があれば、監査可能で復元可能で改善可能な運用層になる。

実装チェックリスト

安定した単一のユーザー向けインターフェースを定義し、内部実行主体は背後に置く。
明示的なスコープとステータスを持つ少数の名前付き作業スレッドを作成する。
非自明なリクエストには、コンテキスト、理由、実行主体、チェックポイント、検証を含むルーティングレシートを使う。
永続メモリ、手順スキル、ソースファイル、トランスクリプト、生成アーティファクトを分離する。
反復可能で決定的な作業はスクリプトまたはスケジュールジョブへ移す。
本番変更を明示する。ローカル検証、コミット、プッシュ、CI、デプロイ、ライブ確認を分ける。
委任された作業は完了報告前に検証する。
プロファイル、スキル、メモリ、cron、スクリプト、設定、リストアノートをバックアップする。
秘密情報はアシスタントのテキストチャネル外に置き、専用のシークレットストアから復元する。
定期的にリストア訓練を行い、証拠を記録する。

運用上の結果

結果として得られるのは、予測可能な挙動を持つ技術的なオペレーション層である。リクエストは単一のインターフェースから入るが、単一の非構造化コンテキストに蓄積されない。作業はルーティングされ、状態は型付けされ、実行は意図的に選択され、副作用は承認され、結果は検証され、システムは別マシンで復元できる。

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