※この記事は2026年5月時点の実運用メモです。
※Codexの公式機能を細かく解説する記事ではなく、自分がブログ作成やObsidian整理で使っていて感じたことの記録です。
※ここでいう「設定」は、細かい機能名だけではなく、AIにどのくらい慎重に見てもらうか、どこまで作業を任せるかという使い方も含めています。
最近、Codexを使う時間がかなり増えている。
ブログのネタ出しをする。
下書きを作る。
公開直前セットを作る。
関連記事を整理する。
Obsidianのinboxを軽くする。
長くなったログをrawに退避する。
必要ならファイルも更新する。
こういう作業を、かなりCodexに任せるようになってきた。
最初は、AIはできるだけ強く使えばいいと思っていた。
深く考えさせる。
慎重に見てもらう。
細かく確認してもらう。
大きめの作業もまとめて任せる。
もちろん、それが必要な場面もある。
ただ、最近は少し考え方が変わってきた。
Codexは、いつも強く使えばいいわけではない。
作業に合わせて、頼み方や重さを変えた方が使いやすい。
今日は、その話を整理しておきたい。
## 何でも重く見てもらえばいいわけではなかった
Codexを使っていると、つい何でもしっかり見てもらいたくなる。
ファイルを読んでほしい。
過去記事との差分を見てほしい。
inboxも確認してほしい。
blog_ideasも更新してほしい。
公開前チェックもしてほしい。
こういう時、Codexはかなり頼りになる。
ただ、全部の作業でそこまで重くする必要があるかというと、そうでもない。
たとえば、ちょっとしたタイトル確認だけなら、そこまで深く読まなくてもいい。
「このタイトルで違和感ある？」
「関連記事の順番だけ見て」
「メタディスクリプションを少し整えて」
このくらいなら、軽く返してもらった方が早い。
逆に、inbox整理や公開直前の判断は、軽く流されると困る。
どのメモを残すのか。
どれをrawに逃がすのか。
投資や会社情報が混ざっていないか。
公開記事として危ない断定がないか。
関連記事が過去記事と自然につながっているか。
こういうところは、少し慎重に見てほしい。
つまり、作業によって必要な重さが違う。
AIを強くするというより、作業に合わせる必要があるのだと思う。
## ブログ下書きでは、勢いと文体を優先したい
ブログ下書きを作る時は、あまり最初から細かく止まりすぎない方がいい。
自分のブログは、きれいな解説記事というより、実運用メモに近い。
やってみた。
引っかかった。
少し考えた。
次はこうしたい。
この流れが大事だと思っている。
だから下書き段階では、細かい正確性チェックよりも、まず記事として読める流れを作ってほしい。
タイトルに対して、導入が自然か。
最近の記事とつながるか。
自分の実感から離れていないか。
結論が強すぎないか。
読者に説明しすぎていないか。
このあたりを見てもらう。
ここでいきなり、細かい出典確認やリスクチェックを全部入れると、本文が固くなることがある。
なので、ブログ下書きではまず書く。
あとから、公開前チェックで危ないところを見る。
この分け方が、今のところはやりやすい。
## 公開直前では、少しブレーキ役になってほしい
一方で、公開直前は少し違う。
下書きでは勢いを大事にしても、公開する時にはブレーキが必要になる。
断定しすぎていないか。
投資助言っぽく見えないか。
特定の会社やサービスを決めつけていないか。
YouTubeの文字起こしをそのまま出していないか。
未確認の数字を事実のように書いていないか。
過去記事と同じことを繰り返していないか。
このあたりは、Codexにかなり見てほしい。
最近の流れでも、下書き段階では気づかなかった危うさが、公開直前セットを作る時に見えてくることがあった。
本文は悪くない。
でもタイトルが少し強い。
関連記事の並びを変えた方がいい。
メタディスクリプションでは断定を弱めた方がいい。
Instagram文面では投資や時事の色を薄めた方がいい。
こういう調整は、公開前にやる方が向いている。
つまり、下書きでは前へ進める。
公開直前では止まるところを見る。
同じCodexでも、役割を変えた方がいい。
## inbox整理では、軽く流されると困る
inbox整理も、軽く済ませにくい作業だと思っている。
inboxには、いろいろなものが混ざる。
ブログ候補。
投資メモ。
仕事ノウハウ。
AIツールの検証。
YouTube視聴メモ。
長いチャットログ。
private寄りの話。
これをただ要約するだけだと、あまり意味がない。
現役のinboxは、次に触る候補だけにしたい。
長いログはrawへ逃がす。
育てる素材はworkbenchへ置く。
公開できないものはprivateとして扱う。
ブログ候補はblog_ideasへつなげる。
次に触る順番を残す。
ここまでやって、ようやく整理した感じになる。
だからinbox整理では、Codexにある程度ちゃんと見てもらいたい。
「要約して」では足りない。
「現役inboxを軽くして、退避先と次の作業順まで残して」くらいまで頼む必要がある。
ここは、軽いモードではなく、少し慎重に進める作業だと思う。
## ファイルを触る作業では、既存の流れを読んでから動いてほしい
Codexにファイルを触ってもらう時は、さらに少し重くなる。
ブログ本文をコピーする。
公開直前パッケージを作る。
関連記事メモを作る。
blog_ideasを更新する。
inboxの公開待ちキューに追加する。
こういう作業は、ただ文章を作るだけではない。
既存のファイル名の付け方。
過去記事の形式。
関連記事メモの並び。
blog_ideasの書き方。
inboxの運用ルール。
これらを見ながら合わせる必要がある。
だから、ファイルを触る作業では、いきなり書き換えられると怖い。
まず読んでほしい。
今の形式を見てほしい。
そのうえで、必要なところだけ更新してほしい。
ここは、Codexの強みが出るところだと思う。
会話だけではなく、実際のファイルを見て作業できる。
ただし、その分、任せ方も少し丁寧にする必要がある。
「いい感じにして」よりも、
“`text
下書きを投稿用最終版にする。
公開直前パッケージを作る。
関連記事メモを作る。
blog_ideasを更新する。
inboxの公開待ちキューに追加する。
既存の形式に合わせる。
“`
このくらい具体的に渡すと、作業が安定しやすい。
## 軽い確認と重い整理を同じ頼み方にしない
最近いちばん感じているのは、軽い確認と重い整理を同じ頼み方にしない方がいいということだ。
軽い確認なら、短く返してもらう。
「このタイトルでいける？」
「関連記事はこれで自然？」
「今日のネタとして強い？」
こういう時は、長い説明より、判断がほしい。
一方で、重い整理なら、ちゃんと手順を踏んでもらう。
「inboxを整理して」
「この下書きをUP版にして」
「過去記事との差分を見て」
「公開前に危ないところを確認して」
こういう時は、ファイルを読んで、必要なら更新して、最後に結果をまとめてほしい。
同じAIでも、作業の種類が違う。
それなのに、毎回同じように頼むと、返ってくるものもずれる。
AIの性能よりも、作業の渡し方の方が効く場面がある。
これは、最近かなり実感している。
## 設定を盛るより、作業の入口を分ける
以前から、自分はAIの個人設定を盛りすぎない方がいいと感じていた。
細かく設定しすぎると、かえって重くなる。
毎回の挙動が分かりにくくなる。
何が効いているのか見えなくなる。
だから、できるだけプレーンに近い状態で使いたい。
ただ、それは何も考えずに使うという意味ではない。
むしろ、設定を盛りすぎない代わりに、作業の入口を分ける。
軽い相談。
ネタ出し。
下書き。
公開直前チェック。
ファイル更新。
inbox整理。
コード修正。
それぞれで、AIに期待する動きが違う。
ここを最初に伝えた方が、細かい設定を増やすより安定するのではないかと思っている。
「いつも最高火力で考えて」ではなく、
「今回は軽く見て」
「今回は過去記事との差分を重視して」
「今回は公開前の危うさを見て」
「今回はファイルを読んでから更新して」
と分ける。
今の自分には、この方が合っている。
## Codexは、強く使うより作業に合わせて使う方が続きそう
Codexを使っていて思うのは、強いAIを使っているだけでは作業は進まないということだ。
何を頼むか。
どのくらい任せるか。
どこで止めるか。
どこからファイルを触ってもらうか。
どこを自分で確認するか。
ここを分ける必要がある。
ブログ下書きなら、まず流れを作ってもらう。
公開直前なら、危ないところを見てもらう。
inbox整理なら、退避と次の作業順まで整えてもらう。
ファイル更新なら、既存の形式を読んでから動いてもらう。
同じCodexでも、作業ごとに期待する役割は違う。
だから、設定は強くすればいいというより、作業に合わせて変えるものなのかもしれない。
AIをうまく使うというのは、強いプロンプトを一つ持つことではなく、今の作業に合う渡し方を選ぶことなのだと思う。
最近の自分には、この感覚がかなりしっくり来ている。
## 関連記事
– AIにブログ記事を見てもらうなら、下書きだけでなく公開直前セットまで作る方が楽だった
コメント