AI活用の話になると、よく出てくるのが「どんなプロンプトを使えばいいですか？」という質問です。
もちろん、プロンプトは大事です。
でも、実務で使っていて感じるのは、プロンプト単体よりも、AIが見に行ける作業環境をどれだけ整えているかの方が大きいということです。
僕の場合、その中心に置いているのが Obsidian です。
Obsidianに、音声日記、発信ルール、事業資料、案件ごとの引き継ぎ、日々の作業ログを貯めておく。
そして Codex から、その情報を読める状態にしておく。
すると、AIはただのチャット相手ではなくなります。
「この人は何を大事にしているのか」
「今どの案件が進んでいるのか」
「どの表記を使うべきか」
「何を触ってはいけないのか」
「前回どこまで進んだのか」
こういう文脈を持った状態で、実務を進められるようになります。
AI活用の差は、プロンプトより文脈で出る
毎回AIに長い説明をしていると、それだけで疲れます。
「僕の事業はこうで、ペルソナはこうで、口調はこうで、ここだけは触らないでください」と毎回説明するのは、かなりしんどい。
だから、毎回説明するのではなく、説明しなくても読みに行ける場所を作ります。
これが、ObsidianをAI活用の中心に置く理由です。
たとえば、記事を書いてほしい時に、
NoahブログのAI活用カテゴリに、CodexとObsidian連携の記事を書いて。
とだけ言っても、AIが過去の記事、カテゴリ構成、文体ルール、保存先、公開フローを読めるなら、かなり具体的に動けます。
これは「プロンプトがうまい」からではありません。
AIが仕事をするための机が、すでに整っているからです。
Codexだけで作るなら、入口はAGENTS.md
Codexでこの仕組みを作るなら、まず入口になるのは AGENTS.md です。
AGENTS.md は、ざっくり言うと「この作業場所では、AIは最初に何を読んで、どう振る舞えばいいか」を書くファイルです。
たとえば、Obsidianのルートに次のようなファイルを置きます。
Obsidian
├── AGENTS.md
├── .codex/
│ └── config.toml
├── .agents/
│ └── skills/
│ └── blog-writing/
│ └── SKILL.md
├── 00_Core/
├── 04_Project/
└── daily-log/
それぞれの役割はこうです。
AGENTS.md：Codexが最初に読む入口.codex/config.toml：Codex側の設定.agents/skills/：繰り返し使う作業手順00_Core/：思想、ペルソナ、発信ルール04_Project/：案件ごとの資料や引き継ぎdaily-log/：日々の音声日記、朝礼、作業ログ
この形にしておくと、Codexに「必要な情報を読んで進めて」と言いやすくなります。
AGENTS.mdには、AIの基本姿勢を書く
AGENTS.md に書くのは、細かいノウハウ全部ではありません。
まずは、AIが迷わないための基本姿勢を書きます。
たとえば、
- 返答は原則日本語
- 音声入力の誤字や表記揺れは、文脈から自然に補正する
- パスワード系のフォルダは読まない
- 削除ではなく、必要ならアーカイブへ移動する
- 開発成果物はObsidian内ではなく、開発用フォルダに置く
- 依頼の種類に応じて、読むべき資料を切り替える
こういうルールです。
ここがあるだけで、AIは毎回ゼロから迷わなくなります。
「記事を書いて」と言われたら発信ルールを見る。
「サイト修正を続けて」と言われたら案件の引き継ぎを見る。
「新しいチャットに移りたい」と言われたら引き継ぎカードを作る。
入口を整えるだけで、AIの仕事の精度はかなり変わります。
繰り返す作業はSKILL.mdにする
毎回同じような作業をするなら、AGENTS.md に全部詰め込むより、スキルとして分けた方が扱いやすいです。
Codexでは、.agents/skills/ の中に SKILL.md を置くことで、繰り返し使う作業手順をまとめられます。
たとえば、
- ブログ記事を書く
- YouTubeを要約する
- LPのデザインをレビューする
- 新チャット用の引き継ぎカードを作る
- Obsidian内のリンクを整える
こういう作業は、毎回ルールを説明するより、スキル化した方が安定します。
イメージとしては、
.agents/
└── skills/
├── blog-writing/
│ └── SKILL.md
├── handoff-card/
│ └── SKILL.md
└── design-review/
└── SKILL.md
という感じです。
AGENTS.md は受付。SKILL.md は作業マニュアル。
この役割分担にすると、AIが必要な時だけ詳しい手順を読めます。
Claude Codeを使っている人は、読み替えでもOK
ちなみに、僕はもともと Claude Code を使っていたので、過去の運用資産には .claude/CLAUDE.md や .claude/skills/ が残っています。
この場合は、無理に全部をCodex用へ作り直さなくても大丈夫です。
AGENTS.md を入口にして、
このvaultはもともとClaude Code前提で育てた構成です。Codexではルールを複製せず、既存の
.claude資産を参照してください。
というように書いておけば、Codex側からも読み替えられます。
ただし、これは少し応用編です。
これから初めて作る人は、まずはCodex標準の AGENTS.md と .agents/skills/ を軸にする方が分かりやすいと思います。
音声入力は、AIを育てる材料になる
僕は音声入力をかなり使います。
きれいな文章を書く前に、まずしゃべる。
思いついたこと、違和感、怒り、迷い、タスク、展望をそのまま入れる。
この素材がObsidianに残っていると、AIは後から引っ張ってこられます。
「たしか数日前に、AI活用3.0の話をしたと思うんだけど」
「この前のNoah開発の続きで、今の不安点を整理して」
「音声日記の中から、記事にできそうなテーマを出して」
こういう雑な依頼でも、材料が残っていれば形になります。
逆に、材料がなければAIは一般論に寄ります。
AIが薄い文章を書くのは、AIが悪いというより、こちらの文脈が渡っていないことが多いです。
コンテキストウィンドウは、AIの作業机みたいなもの
ここで一つ、AIを使う上で知っておきたい概念があります。
それが コンテキストウィンドウ です。
難しく聞こえますが、ざっくり言うと「AIが今のチャット内で一度に見られる情報量」です。
Codexでやり取りしていると、会話、読んだファイル、実行結果、スクリーンショット、修正内容などが少しずつ文脈として積み上がっていきます。
画面下にある円グラフのようなメーターが増えていく感覚です。
Codex context window meter example An explanatory diagram showing how a Codex conversation accumulates context and approaches the context window limit. Codex thread 会話、ファイル、実行結果が少しずつ文脈として積み上がる記事作成、コード修正、調査、スクリーンショット確認... Startまだ軽い。前提が少なく、応答も安定しやすい。 Later in the same thread重くなる前に、要点を引き継ぎカードへまとめる。 75%context画面下のメーターが増えていく感覚 対処法要点だけを残して新しいチャットへ。過去ログは必要な時だけ参照する。最初は軽いです。
でも、長く作業していると、だんだん重くなります。
文脈が増えすぎると、
- 返答が遅くなる
- 前提が混ざる
- 古い話を引きずる
- 指示の解釈が少しズレる
- どこまで終わったか分かりにくくなる
ということが起きやすくなります。
だから、長い作業では「どこかで整理して渡し直す」ことが大事です。
重くなったら、引き継ぎカードを作る
コンテキストが重くなった時に使っているのが、引き継ぎカードです。
引き継ぎカードには、次のような内容を書きます。
- 目的
- 現在地
- 対象フォルダやリポジトリ
- 直近で完了したこと
- 次にやること
- 触ってはいけないもの
- 未確認の不安点
- 新しいチャットの最初に貼る依頼文
これを作ってから新しいチャットを開くと、コンテキストを軽くした状態で作業を続けられます。
ここで大事なのは、過去ログを全部読ませないことです。
過去ログは保険として残す。
新しいチャットでは、まず引き継ぎカードだけ読む。
足りない時だけ過去ログを見る。
この順番にすると、AIの動きがかなり安定します。
Obsidianには文脈を置き、開発ファイルは分ける
もう一つ大事なのが、Obsidianを何でも置き場にしないことです。
Obsidianは文脈の保管庫としては強いです。
でも、HTML、CSS、JS、画像素材、ZIP、アプリ本体などを全部Obsidianに入れると、役割が混ざります。
僕の運用では、開発成果物は開発用フォルダに置きます。
Obsidianには、
- 何を作るのか
- なぜ作るのか
- どこまで進んだのか
- 次に何をするのか
- 誰に確認するのか
という文脈を置く。
実際のコードや画像などのファイルは、開発用フォルダで管理する。
この分け方をすると、AIにも指示しやすくなります。
背景はObsidianを読んで。実装はこのリポジトリでやって。
こう言える状態がかなり強いです。
AIへの指示は、上司力が出る
AIは便利ですが、雑に投げると雑に返ってきます。
実務でよく使う指示の型は、次のようなものです。
- あなたが実行してください
- 目的はこれです
- 完了状態はこうです
- 触っていい範囲はここです
- 触ってはいけない範囲はここです
- 分からない場合は調べて、選択肢とメリット・デメリットを出してください
- 最終的に僕がやることは少なくしてください
これはAI用の特殊な話というより、人に仕事を渡す時と同じです。
新入社員に「いい感じにやって」と言って、違うものが出てきたら困るのはこちらです。
だから、最初の指示で仕事の範囲を決める。
ここを丁寧にやるほど、後のラリーが減ります。
小さな運用が積み上がると、AIは実務パートナーになる
CodexとObsidianの連携は、派手な魔法というより、細かい運用の積み重ねです。
AGENTS.mdで入口を作る- 繰り返す作業は
SKILL.mdに分ける - 音声入力を素材として残す
- 日々の作業ログを残す
- コンテキストが重くなったら引き継ぎカードを作る
- Obsidianには文脈を置き、実ファイルは開発フォルダに置く
- パスワードや機密情報は読ませない
- 外部協力者がいる作業は、勝手にpushしない
一つひとつは地味です。
でも、これがあるとAIがかなり実務向きになります。
「AIに聞く」から、
「AIと一緒に仕事を進める」に変わります。
最後に：AIは、文脈を育てた分だけ仕事がしやすくなる
僕がこの仕組みを使っていて一番感じるのは、AI活用は単発の便利技ではないということです。
1回の神プロンプトで全部解決するというより、毎日のログ、音声メモ、発信ルール、引き継ぎカード、作業履歴が少しずつ蓄積されていく。
その蓄積があるから、次の仕事が速くなる。
AIを育てるというのは、AIそのものを変えるというより、AIが見に行ける自分の文脈を育てることです。
Obsidianは、その文脈の置き場。
Codexは、その文脈を読みながら手を動かす実務担当。
この役割分担ができると、AIはかなり心強いパートナーになります。
プロンプトを磨く前に、まずは文脈の置き場を作る。
ここから始めるだけで、AI活用の体験はかなり変わります。