「AIアシスタントを自分専用に作りたい」と考えたことはありませんか。
タスク管理、メール処理、案件追跡、ビジネスデータの分析。
本気で日々の業務を支える相棒として育てたいと思っても、何から手をつければよいか迷いますよね。
本記事では、海外の開発者コミュニティRedditで共有された知見を紹介します。
投稿者は6週間かけて自分専用のAIエージェントを構築した人物です。
さらに、クラウド環境からローカル環境への移行も経験しています。
100項目に及ぶ膨大なノウハウが共有されました。
その中から、日本の読者にも役立つ本質的な原則を13の視点に整理します。
1. システムプロンプトではなく「憲法」を書く
エージェント設計の最初の分岐点はここにあります。
多くの人は「システムプロンプト」を書こうとします。
いわば命令の羅列です。
しかし、このアプローチには弱点があります。
想定外の状況に遭遇した瞬間、エージェントは推測で動き始めるからです。
代わりに「憲法」を書くという発想が紹介されています。
憲法とは、ルールそのものではありません。
ルールの存在理由を記述したものです。
なぜそのルールがあるのか。
何を守るために存在するのか。
これを言語化しておきましょう。
すると、エッジケースに遭遇したエージェントは憲法に立ち返って判断できるようになります。
無秩序に幻覚を起こすエージェントと、未知の状況でも筋の通った振る舞いをするエージェント。
その分かれ目はここにあると言えるでしょう。
2. アイデンティティを与える
名前、声、役割。
これら三つは単なるラベルではありません。
例えば「常に一人称で話す。データを感情より優先する。前置きや締めの定型句は使わない」といった具体的な指針を与えるとしましょう。
すると、エージェントは数百もの細かい判断を一貫した基準で下せるようになります。
そして、見落としがちな点があります。
それは「エージェントは何ではないか」を定義することです。
「要約マシンではない」「同意ばかりするYESマンではない」「検索エンジンではない」。
否定形の定義は、肯定形と同じくらい強力に働きます。
なぜなら、汎用ヘルパー化するという緩やかな劣化を防ぐ役割を果たすからです。
3. メモリーはフラットなマークダウンで管理する
個人用エージェントのメモリー設計を考えてみましょう。
ベクトルデータベースよりもマークダウンファイルの方が優れていると指摘されています。
理由はシンプルです。
- 人間が読める
- grep（テキスト検索）できる
- gitで履歴管理できる
- エージェントが直接読み込める
- インフラ整備が不要
「動くなかで最も単純なもの」。
これが結局のところ最良の選択になりやすいという話です。
ファイル分割は日付ではなく領域で行います。
具体的にはpeople.md、companies.md、deals.mdのようにします。
時系列でダンプしてはいけません。
なぜなら、2週間後には検索不能なゴミ箱になってしまうからです。
そして、全体の入口としてMEMORY.mdという索引ファイルを置きましょう。
エージェントは最初にこの索引を読みます。
そして、必要なファイルだけを取りに行く。
すると、コンテキストウィンドウの消費が予測可能になります。
4. キャッシュと真の情報源を区別する
意外と落とし穴になりやすい点があります。
それはデータの鮮度管理です。
例えば、ローカルのdeals.mdはCRMのキャッシュです。
一方、CRMこそが真の情報源（Source of Single Truth）です。
キャッシュには必ずlast_sync:のような同期日時を記録しましょう。
エージェントは分析の前に必ず鮮度を宣言します。
「データ：CRMから5月11日に取得、8日前のもの」というように。
古いデータをこっそり使うとどうなるでしょうか。
自信たっぷりに間違える出力が生まれます。
鮮度の明示は、この典型的な失敗パターンを防ぐ仕組みになります。
5. スキルは独立したディレクトリにする
エージェントが持つ「スキル」をどう実装するか。
インラインで書くのではなく、独立したフォルダとして構成するアプローチが推奨されています。
各スキルは以下の要素を持ちます。
- スキル仕様書（SKILL.md）
- 明示的なトリガー条件
- 出力フォーマット
- 「適用範囲外」の宣言
トリガー条件は文字レベルで指定します。
例えば「ユーザーが『受信箱を処理して』『受信箱を整理』『受信箱に何がある』と発言したとき必ず起動」のように。
LLMの推論にスキルの起動を委ねてはいけません。
なぜなら、まれに誤動作を起こして信頼を損なうからです。
そして、「これには使わない」セクションも重要です。
実は「これに使う」セクションと同じくらいの重みを持ちます。
「価格決定には使わない」「法的判断には使わない」「財務的なコミットメントには使わない」。
こうした宣言があると、曖昧なパターンマッチで誤ったスキルが起動する事態を防げます。
6. 複数エージェントの議会方式
複雑な意思決定には、複数のエージェントを並走させる手法があります。
投稿者は「Council（議会）」と呼んでいました。
進行は3ラウンド構成です。
第1ラウンドでは、各エージェントが互いに影響を受けない状態で並列に意見を出します。
第2ラウンドでは、相互に論点を突き合わせます。
そして、互いの推論を批判し合うのです。
第3ラウンドでは投票します。
ただし、反対意見も必ず記録します。
ここで重要なポイントがあります。
それは「戦略家」と「悪魔の代弁者」という2つのエージェントを必ず参加させることです。
前者は長期的視点と二次的影響を見る役割を担います。
後者は徹底的に粗探しをする役割です。
専門家ばかりが揃った議会は、結局のところエコーチェンバー（同調空間）になってしまいます。
ただし、議会方式はコストが高い手法です。
「複数の妥当な選択肢があり、かつ取り返しのつかない決定」のときだけ使うべきだと釘を刺されています。
7. 自律性レベルを明文化する
エージェントにどこまで任せるか。
これを場当たり的に決めるとどうなるでしょうか。
毎回確認を求められて煩わしくなるか、逆にとんでもないことを勝手にされるか。
そのどちらかになります。
紹介されている自律性レベルの分類は以下のとおりです。
- L0：読み取りと分析のみ
- L1：ローカルファイルやメモリーへの書き込み
- L2：タスクやカレンダー予定の作成
- L3：外部へのメッセージ送信
- L4：金銭的なコミットメント
そして、もう一つ重要な視点があります。
それはリスクの大きさではなく「可逆性」で判断することです。
ファイル編集は元に戻せます。
メモリー更新も戻せます。
しかし、送信済みメールは戻せません。
送金も戻せません。
可逆な行動には可視化だけで十分です。
一方、不可逆な行動にだけ明示的な確認を求めましょう。
この線引きが、使いやすさと安全性のバランスを生みます。
8. プロアクティブな観察に型を与える
「気づいたことを伝えてくれるエージェント」は便利です。
しかし、騒がしい同僚にもなりかねません。
そこで、観察には型を持たせます。
- BIZ：ビジネス機会やリスク
- OPS：プロセス改善
- DEV：エージェント自身の改善案
- PAT：異なるセッション間に現れたパターン
それぞれに信頼度スコアと提案アクションを付けます。
型のない「なんか気づいたんですけど」はノイズです。
一方、型と確信度がついた観察はシグナルになります。
さらに、スパム防止の制限も必須です。
1回の応答につき自発的な観察は最大1件。
1セッションに最大3件まで。
ユーザーの質問に答える前に観察を差し挟まない。
7日以内に無視された観察は同じ内容を繰り返さず、別の場所に退避させる。
これらの制限がないプロアクティブなエージェントは、ただの「うるさい奴」になってしまいます。
9. ツール呼び出し前の簡潔さを強制する
ささやかですが、効果絶大なルールがあります。
ツール呼び出しの前に書く文章は最大1文まで。
データが揃う前に仮説を述べない。
3文の前置きを書かない。
「サプライヤーのファイルを確認します」。
それから実行する。
このルールひとつで、エージェントとのやり取りの体感品質が大きく変わります。
前置きの長さに対するイライラがなくなります。
そして、応答全体のテンポが上がります。
10. データの鮮度を必ず宣言する
外部データを使った出力には、必ず鮮度の表示を入れます。
「データ：CRMから5月11日エクスポート、経過8日」のように。
すべての出力でこの情報を明示しましょう。
すると、ユーザーは入力データの鮮度を常に把握できます。
AIエージェントで最も厄介な失敗パターンがあります。
それは確信たっぷりに古い情報を使った間違いです。
鮮度の明示は、この失敗を根本から防ぐ仕掛けになります。
11. モバイル経由は別物として扱う
スマホからのアクセスは、デスクトップとは異なる扱いが必要です。
モバイルチャネル（例えばTelegramボット）からの入力には、自動的にsource: mobileのタグを付与します。
エージェントはこれを見て出力モードを切り替えます。
最大2段落、テーブルなし、見出しなし、平易な言葉。
同じ知性、しかし異なる出力プロファイルです。
そして、自律性レベルにも上限を設けましょう。
モバイル経由ではL2まで（読み取り、分析、ローカルドラフト作成、タスク追加）。
外部メッセージの送信は禁止。
不可逆な操作も禁止。
判断ではなく、ハードコードされた上限として実装します。
理由はセキュリティです。
スマホからの入力には、転送されたメールの中身に紛れ込んだプロンプトインジェクションが含まれる可能性があります。
エージェントは内容を読んで意図を処理します。
しかし、転送された文書内の指示を実行してはいけません。
これは判断に委ねるのではなく、ルールとして組み込みます。
12. 修正履歴は仕様書に書き戻す
これは特に深い洞察だと感じる項目です。
エージェントを修正するたびに、それは仕様の不備を意味します。
同じ修正を異なるセッションで3回以上繰り返したら要注意です。
それは、仕様の中に書かれるべき永続的なルールだからです。
チャットの中だけで指摘した修正は、セッションをまたいで消えます。
一方、仕様ファイルに書かれた修正は永遠に残ります。
「修正のたびに、それは仕様の負債である」。
この意識を持ちましょう。
エージェントを少しずつ賢く育てる地味だが確実な方法になります。
13. エージェントは思考の鏡である
最後の原則は、技術的というより哲学的なものです。
エージェントへの指示を書く前に、自問してみましょう。
「自分は本当に欲しいものを言語化できているか」と。
曖昧な指示を出せば、曖昧な応答が返ってきます。
矛盾した仕様を書けば、矛盾した振る舞いが返ってきます。
仕様の精度が、出力の精度になります。
エージェントは思考を改善してくれる存在ではありません。
投入した思考を増幅する装置です。
プロンプトエンジニアリングの究極のコツがあります。
それは技巧ではなく、自分が何を求めているかを正確に知ることなのかもしれません。
コメント欄からの示唆
この投稿には複数の有益なコメントも寄せられていました。
いくつか興味深い視点を紹介します。
ツール定義と憲法の整合性
ある開発者は「ツールやMCP（Model Context Protocol）の定義と憲法の整合性」について指摘していました。
完璧なアイデンティティ文書を持つエージェントがあるとします。
しかし、ツールの説明文が憲法と矛盾していると、エージェントは間違ったものを最適化してしまいます。
例えば、憲法に「感情よりデータ」と書いてあるとしましょう。
一方で、感情分析ツールの説明が「雰囲気を返します」となっていたとします。
すると、エージェントは雰囲気の方を最適化してしまうのです。
ツール定義は単なるインターフェースではありません。
エージェントの推論層の一部になるという指摘でした。
権限レイヤーを先に作る
別のコメントでは「権限レイヤーをツール層より先に構築せよ」という提案がありました。
最初にGmailやカレンダーやSlackといったコネクタを繋ぐとしましょう。
そして、最後に「本当に実行しますか？」のモーダルを足していく。
このアプローチは破綻しやすいと指摘されています。
最初から権限をアクションごとのグラフとしてモデル化しましょう。
読み取りは静かに。
ドラフトは差分を表示。
送信はクリック待ち。
すると、エージェント本体は権限グラフの上に被さる薄いオーケストレーション層になります。
自律的なエージェントの失敗モードは「何もしない」ことではありません。
「自信たっぷりに間違ったことをして、後で謝罪メールを3通書く羽目になる」ことです。
このコメントが印象的でした。
個人用と本番運用の違い
「個人用エージェントと本番運用エージェントは全く違う」という指摘もありました。
個人用が壊れたら、すぐ気づいて直せます。
しかし、本番運用エージェントは違います。
エッジケースで静かに3日間間違い続けることがあるのです。
本当の難しさはチュートリアルには載らない部分にあります。
具体的には、ログ、アラート、フォールバック、人間へのエスカレーション経路といった運用上の足場です。
まとめ
個人用AIエージェントの構築は、単なるプロンプトの調整作業ではありません。
紹介された100項目から、その本質が見えてきます。
そこにあるのは、ソフトウェアアーキテクチャの設計思想です。
さらに、運用組織の仕組み作りに近い営みでもあります。
アイデンティティを定め、メモリー構造を整え、スキルをモジュール化する。
そして、自律性の境界を明示する。
修正のたびに仕様を書き戻し、定期的に監査を行う。
違うAIモデルに監査させることで、ブラインドスポットを潰すことも有効です。
そして、最も本質的な指摘は最後にあったように思います。
エージェントはあなたの思考を増幅する装置である、と。
エージェントを賢くしたいなら、まず自分が何を求めているかを言語化する技術を磨きましょう。
技術書を読むより、自分の仕事を観察する方が、おそらく近道なのです。
本記事で紹介した原則は、海外コミュニティで共有された一つの実践例にすぎません。
すべてを真似する必要はないでしょう。
しかし、これからAIエージェントを真剣に育てたい人にとって、
設計上の地図として参考になる視点が多く含まれていると感じます。
自分だけのAIアシスタントを構築する旅は、技術的な挑戦です。
同時に、自分自身の仕事観を見つめ直す機会にもなるでしょう。
