チャットAIやCLIでは「自律サービス」は作れない：AIエージェントに必要なアーキテクチャ
はじめに
ChatGPTやClaudeを毎日使っています。Claude CodeやCodex CLIでコードを生成・修正させることも当たり前になってきました。AIの活用が、自分の仕事の中に確実に入り込んできています。
ではその延長で、「朝7時にGmailを確認して、対応が必要なメールだけをSlackに通知する」ような仕組みは作れるでしょうか。
答えは「チャットとCLIのままでは、作れない」です。そしてそれは、AIの性能の問題ではありません。アーキテクチャの問題です。
これまで、AIがプロダクトの競争軸をどう変えるか、エージェントが業務にどう統合されるかを俯瞰してきました。今回はその構造を、個人が自律サービスを作る場面まで降ろして考えます。
過去の記事
チャットAIとCLI AIは「起動されるもの」である
チャットもCLIも、設計上の前提が同じです。
人間が操作した瞬間だけ動く
セッションを開けば動きます。閉じれば止まります。PCがスリープすれば止まります。定刻に自動で起動はしません。前回の会話や処理結果を、サービスとして継続的に引き継ぐわけでもありません。
これはAIの限界ではなく、インターフェースの設計です。チャットはあくまで人間と対話するための窓口として作られています。CLIは、人間が開発作業の中で呼び出すための道具です。
つまり、どちらも「人間が起動するもの」です。「人間がいる間だけ動く」は、バグではなく仕様です。
問題は、ここで多くの人が止まってしまうことです。チャットやCLIが強力だからこそ、「これで自律的なものが作れるはず」と思いやすい。しかし、自律サービスに必要なのは、チャットやCLIの延長ではなく、別の実行構造です。
自律サービスに必要なのは、賢いモデルではなく実行構造
「自律する」とはどういうことでしょうか。それは、モデルが賢くなることではありません。人間がその場で操作しなくても、決められた条件で起動し、外部サービスと連携し、状態を保持し、結果を通知し、失敗時にも制御できることです。
そのためには、少なくとも次の要素が必要になります。
Scheduler（スケジューラ）
いつ、何をきっかけに動き出すかを制御します。定時実行、Webhookによる外部イベント、キューへの投入など、人間の操作なしに処理を開始する仕組みです。
Runner（実行基盤）
処理を実際に動かす環境です。PCがスリープしても止まらないためには、クラウド上の常駐プロセスかサーバーレス実行環境が必要になります。
Agent Core（エージェント本体）
AIへのリクエストを組み立て、ツールの使用を制御し、処理の流れを管理するロジックです。ここにClaude APIなどが組み込まれます。AIはこのCoreから呼ばれる部品であって、Coreそのものではありません（※後述の図1における「あなたのコード」に該当する部分です）。
Tools / Connectors（外部連携）
GmailやGoogleカレンダー、Slackといった外部サービスへの接続です。AIが「このツールを使うべき」と判断しても、実際にAPIを叩くのはこのレイヤーのコードです。AIは判断や指示を返しますが、外部サービスへの接続そのものは自分のシステムが担います。
State Store（状態管理）
処理済みメールのID、前回の実行結果、会話の文脈などを保存する場所です。AIには、サービスとしての継続的な記憶はありません。前回の処理を踏まえて動かしたいなら、その状態は自分のシステム側で永続化する必要があります。
Notification（通知）
処理結果をどこにどう届けるか制御します。Slackへの投稿、メールの送信、ダッシュボードへの書き込みなどを制御します。
Guardrails（制御・安全策）
失敗したときに止まるか、リトライするか。誤った操作を防ぐ権限管理。コストが跳ねていないかの監視。自律的に動くほど、暴走を止める仕組みが重要になります。
自律性に必要なのは、モデルの性能だけではありません。これらの実行構造です。チャットAIやCLIに欠けているのはモデルの賢さではなく、この構造全体です。
AI APIは「脳」ではなく、ワークフロー内の判断部品
構成を理解するために、まずはAI APIのリクエスト構造と、ツール呼び出し（MCP）のループを見てみましょう。
ここで、AI APIが何者かを整理しておきましょう。
Claude APIへのリクエストは、大きく3つのパラメータで成り立ちます。system（役割・制約の定義）、messages（会話履歴と今回の指示）、tools（使える外部機能の宣言）です。
重要なのは、これがリクエストのたびに組み立て直されるという点です。AIに記憶はありません。「前回の処理を踏まえて」動かすためには、前回の結果を自分のサービス側で保存しておき、次のリクエストに含める必要があります。継続性はAIではなく、システムが作り出すものです。
ツール連携（MCPを含む）も同様の構造です。「post_to_slackというツールが使える」とAPIに宣言すると、Claudeはそれを使うべきと判断したとき「このツールをこの引数で呼んでほしい」という指示を返します。実際にSlackのAPIを叩くのは自分のコードです。結果をClaudeに返すと、Claudeが次の判断を行います。
AIはワークフローの中の部品です。判断・分類・要約・生成を担う非常に強力な部品ですが、ワークフローと状態は自分のサービス側が持ちます。チャット画面が隠蔽しているのは、まさにその「部品を呼び出している仕組み」の全体です。
ローカルPCで動くものは、サービスではなくアプリ
Claude Codeを使えば、上述の構成を持つスクリプトは短時間で書けます。動くコードも生成されます。「自分用のAIサービスができた」と感じる瞬間があります。しかし、それをローカルPCで動かす限り、自律サービスではありません。
PCがスリープすれば止まります。電源を切れば止まります。Wi-Fiが切れれば止まります。cronで定時実行を設定しても、その前提はPCが起きていることです。
ここで区別すべきなのは、「自分用アプリ」と「自分用サービス」です。
- アプリは、あなたが起動します
- サービスは、あなたがいなくても動きます
「自分用アプリ」と「自分用サービス」は、まったく別物です。
ローカルPCで動くものは、どれだけ高度なロジックを持っていても、基本的には前者です。もちろん、ローカルでの試作は正しいアプローチです。検証フェーズとしては、コストも低く、デバッグもしやすい。最初からクラウドに載せる必要はありません。問題は、そこで完成と思ってしまうことです。
ローカルで動いたものを、自律サービスにするためには、実行基盤、スケジューラ、状態管理、監視、権限管理を別途設計する必要があります。
現実的な構成：ローカルからクラウド実行基盤へ
では自律サービスにするためにどうすればよいでしょうか。段階的な移行が現実的です。
ローカル環境のDockerで検証する
最初は、ローカルPC上でDockerコンテナとして動作環境を固めます。「手元で動く」状態をコンテナとして定義しておくことで、次のステップへの移行コストが大きく下がります。
依存ライブラリ、環境変数、外部API接続、状態管理の方法を、コンテナとして定義しておく。これにより、「自分のPCでは動くが、別の環境では動かない」という問題を減らせます。ローカルでは、cron相当の仕組みや簡易スケジューラで定時実行を検証すれば十分です。
次にクラウドに移行する
AWSであれば、EventBridgeでスケジュール実行をトリガーし、FargateやLambdaで処理を動かします。GCPであれば、Cloud SchedulerとCloud Runの組み合わせになります。
状態管理は、RDS、DynamoDB、Cloud SQL、Firestoreなどのマネージドなデータストアに移します。ここで重要なのは、エージェントのロジック自体は大きく変えないことです。図2にある通り、コードはPhase 1（ローカル）の時点からほぼ変わりません。 変わるのは、主に「どこで動かすか」というインフラのレイヤーだけです。
外部サービスと接続する
GmailやGoogleカレンダーはGoogle APIで、Slack通知はSlack APIで接続します。これらはAIとは独立した接続です。
AIがどう判断するかに関わらず、認証、権限、API呼び出し、エラーハンドリングは自分のコードが持ちます。AIは判断します。しかし、接続し、実行し、記録し、通知するのはシステムです。この分離を意識しておくことが、自律サービスを設計する上で重要になります。
いずれクラウドサービスに吸収されるからこそ、今は自分で作る価値がある
この構成を自分で作る作業は、いずれ不要になる可能性が高いです。
スケジューラ、状態管理、ツール連携、通知、権限管理。これらを束ねたエージェントホスティングのマネージドサービスは、AIベンダーやクラウドプロバイダーによって整備されていくはずです。各社のエージェント実行基盤や、開発支援AIのバックグラウンド実行機能にも、その方向性は見え始めています。
今、自分でゼロから作っているものは、数年以内に「設定するだけ」になるかもしれません。それでも今、自分で作る価値があります。理由は2つです。
ひとつは、構造を身体で理解できることです。マネージドサービスは、多くの仕組みを隠蔽します。隠蔽されている仕組みを知っている人と知らない人では、問題が起きたときの対応力がまったく違います。
もうひとつは、どこをAIに任せ、どこをシステムで制御すべきかが分かることです。AIに任せていい判断と、明示的な制御が必要な処理は異なります。たとえば、メールの要約や優先度分類はAIに任せやすい。一方で、メールを削除する、外部に送信する、課金が発生する操作を行う、といった処理は、明示的な制御や人間の確認を挟むべき場面が多い。この境界を、体験なしに引くことは難しい。
過渡期に自分で作ることが、その感覚を育てます。
おわりに
「AIで自分用アプリが作れる」は本当です。しかし、ローカルPCで動くアプリは、自律サービスではありません。自律性を作るのはモデルの賢さだけではなく、スケジューラ、実行基盤、状態管理、権限、通知、失敗時の制御です。AIはその仕組みの中の一部品として呼ばれます。
チャットやCLIが強力なのは確かです。しかし、強力なインターフェースと、24時間稼働するサービスは別の話です。そこを繋ぐのは、アーキテクチャの理解です。
AIエージェントを作るとは、AIに命令することではなく、AIが安全に動き続けられる実行構造を設計すること です。
Discussion