個人AIエージェントを実務のアシスタントとして動かすには: Hermesに学ぶメッセンジャー、知識庫、スキル、ヘルスチェック設計

1. 概要: エージェントは大きなチャット画面ではない

多くの人はAIをチャット画面として体験します。そのためエージェントも、画面に出た答えだけで評価しがちです。しかし業務アシスタントは、答えがうまいだけでは足りません。依頼を受け、会社の文脈を理解し、ツールを使い、固定ルールを守り、危険な作業では承認を求め、証拠を残し、人が席にいない時でも到達できる必要があります。

だからHermesは良いケーススタディです。重要なのは秘密のプロンプトではありません。モデルの周囲にあるラッパーです。Telegramは依頼を受ける入口、ローカルランタイムは実際の実行環境、Codexのようなproviderは推論と実行を担う部分です。Obsidianは知識の表面、MCPはツールとデータの接続、skillsは反復手順、healthcheckはシステムが生きていることを証明する仕組みです。

公式ドキュメントも同じ方向を示しています。OpenAIはエージェントアプリを、計画し、ツールを呼び出し、状態を保ち、承認と可観測性を必要とするシステムとして説明しています。MCP文書はAIアプリケーションを外部システムにつなぐ標準を説明しつつ、敏感なツール呼び出しには人間の確認とログが必要だとしています。Xのローカルインボックスで見えた現場シグナルも同じです。ビルダーは「より良いプロンプト」から「AIを運用システムに組み込む方法」へ移っています。

2. やさしい用語: ゲートウェイ、ランタイム、MCP、スキル、メモリ、ヘルスチェック

ゲートウェイは、人間とエージェントの間の扉です。HermesではTelegramがその役割を持ちます。簡単に言えば、コーディングアプリやダッシュボードを開かなくても、スマートフォンから業務依頼を投げられるということです。

ランタイムは、エージェントが実際に動く場所とプロセスです。providerは推論と実行を担当するモデルまたはバックエンドです。MCP、つまりModel Context Protocolは、AIがデータ、ツール、ワークフローにつながるための標準ソケットです。MCPは脳ではなく接続端子です。

スキルは再利用できる業務レシピです。メモリはセッションが変わっても毎回説明し直すべきではない安定した文脈です。ヘルスチェックは重要な部品がつながっていることを反復して証明するテストです。Failure Packetは小さな事故記録です。何が失敗したか、どんな信号があったか、なぜ起きたか、次にどのルールで防ぐかを書きます。

• Gateway: 依頼が入る扉。
• Runtime: エージェントが動く機械やプロセス。
• Provider: 推論と実行を担当するモデルまたはバックエンド。
• MCP: ツール、ファイル、API、ワークフローをつなぐ標準通路。
• Skill: 反復業務のための再利用手順。
• Memory: 毎回説明し直さない安定文脈。
• Healthcheck: システムが接続されていることを証明する反復テスト。
• Failure Packet: 失敗を次の運用ルールに変える短い振り返り記録。

3. なぜメッセンジャー入口が重要なのか

メッセンジャー入口は単純に見えるので過小評価されがちです。しかし導入の摩擦を大きく減らします。優れた自動化でも、特定のPC、特定のrepo、特定のターミナルを開かなければ使えないなら、実務の速度には乗りません。Telegramはエージェントを、いつでも近くにある入力面にします。

ビジネス価値は「どこでもチャットできる」という珍しさではありません。捕捉速度です。創業者は顧客課題をその場で渡せます。チームリードは出典付き要約を頼めます。運用担当者は作業環境全体を開き直さず、日次チェックを依頼できます。

ただし、この扉は狭くあるべきです。メッセンジャーは読み取り、下書き、要約、分類、キューイングに強くあるべきです。ファイル削除、顧客メッセージ送信、決済、本番変更のような作業は、黙って実行されてはいけません。ゲートウェイが現実の副作用を起こせる瞬間、承認とログは任意機能ではなく製品の一部になります。

4. 知識庫: エージェントに必要なのはノートの山ではなく信頼できる情報源

最もよくある失敗は、古い、または部分的な文脈から出る自信満々の答えです。Obsidianが強いのは、会社の知識をプレーンなノートとして長く保てるからです。意思決定、SOP、出典リンク、プロジェクトルール、調査ログ、日々の文脈を蓄積できます。Obsidian Local REST APIは、vaultを認証付きREST APIとMCPサーバーとして公開し、AIが読み、検索し、許可された場合に編集できる実装例です。

重要なのは「許可された場合」です。知識庫をエージェントにつなげても、自動的に安全になるわけではありません。最初の運用ルールはread、search、listを優先することです。書き込み、追記、パッチ、移動、削除は、明確な対象と理由がある場合だけ許可します。MCPは便利ですが危険にもなります。ツールアクセスを簡単にするため、権限境界も同時に見える必要があります。

Anthropicが言うcontext engineeringは、この問題をより大きな名前で呼んだものです。モデルの前に、どの文脈をいつ置くかを設計する仕事です。小さな会社が初日から巨大な知識グラフを作る必要はありません。まずは1枚のworkflow cardから始めれば十分です。担当者、最終更新日、出典リンク、例、例外、承認ルール、禁止行動を入れたカードです。

5. スキルとメモリ: 同じ説明を毎回繰り返さない

Xインボックスで何度も見えた痛みは1つです。人はAIセッションを開くたびに、同じ説明を繰り返すことに疲れています。文体、プロジェクト制約、好みのワークフロー、禁止行動、出典の優先順位は、その日のチャット画面だけに置くべきではありません。プロジェクトルール、メモリファイル、スキルに変えるべきです。

スキルは魔法ではありません。反復業務のための再利用プレイブックです。ブログ記事を調査する方法、route checkを行う方法、危険なgitコマンドを確認する方法、顧客返信を準備する方法、ローンチ課題を分類する方法です。手順が書かれていれば、エージェントはすべての詳細を常時プロンプトに抱えず、必要な時に読み込めます。

メモリにも節度が必要です。永続メモリは長く使う事実と好みを持つべきで、すべての一時的な思考を保存する場所ではありません。より良い形は層を分けることです。常に読む小さなbriefing、必要時に読み込む詳細skill、証拠が必要な時に検索するsource noteです。

6. 承認とツール境界: つなぎ過ぎず、より多く証明する

エージェントを作る悪い方法は、すべてのツールをつないで生産性と呼ぶことです。ツールが増えれば可能なことは増えますが、偶発的なデータ露出、誤った書き込み、責任境界の混乱も増えます。MCPのツール仕様も、敏感な作業には人間の確認、明確な表示、入力検証、タイムアウト、監査ログが必要だと説明しています。

OpenAI Codexの承認とsandbox文書も同じ運用形を示しています。制御されたworkspaceの中では読み書きし、境界を越える作業や副作用の大きい作業では承認を求める。これは官僚主義ではありません。エージェントを有用にしながら、人間が責任を保つための方法です。

したがって良いHermes型ラッパーはwhitelistから始まります。メッセンジャーが何を実行できるのか、エージェントが何を読めるのか、どのツールは読み取り専用なのか、どの行動に承認が必要なのか、どの行動は禁止なのか、実行後の証拠をどこに残すのかを先に決めます。

7. ヘルスチェック、ログ、Failure Packet

エージェントが運用の一部なら、「昨日は動いた」では足りません。ゲートウェイは切断されるかもしれません。OAuthは期限切れになるかもしれません。Obsidianが閉じているかもしれません。ローカルMCP endpointが失敗するかもしれません。起動エントリが壊れるかもしれません。モデルやprovider設定が変わるかもしれません。ヘルスチェックがなければ、最初の発見者は仕事を待っていた人になります。

ヘルスチェックは退屈で反復可能であるべきです。ゲートウェイプロセスは動いているか、providerに届くか、知識庫に届くか、ツール一覧を見られるか、無害なテスト依頼を完了できるか、ログが残るかを確認します。この差がデモと実際のアシスタントの差です。

2つ目のループはFailure Packetです。同じ失敗が繰り返されるなら、手で直して終わりにしてはいけません。incident、signal、root cause、prevention rule、closeout proofを残します。こうして個人スクリプトは、毎週良くなる運用システムになります。

8. 会社ではどう過剰に作らず導入するか

小さなチームの最初のHermes型エージェントは、会社全体を管理すべきではありません。リスクが低く、出典が明確な反復業務を1つ選びます。日次知識ダイジェスト、顧客質問のtriage、lead research、ローンチチェックリストレビュー、ブログ調査brief、社内SOP検索などです。

次に最小の運用ラッパーを作ります。1つのメッセンジャー入口、1つのsource-of-truthフォルダ、1つの作業チケット形式、1つか2つの読み取り優先ツール、1つの承認ルール、1つのヘルスチェック、結果を残す1つのログ場所です。2週間うまく回ったら、その時にツール1つ、またはworkflow1つを足します。

ここで人間もAIと一緒に成長する必要があります。モデルが強くなるほど、人間の強みはすべての答えを自分で書く力から、業務システムを設計する力へ移ります。出典の優先順位、権限境界、escalation rule、品質基準、feedback loopを設計できる人は、AIによって重要でなくなるのではなく、より重要になります。