※この記事は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にブログ記事を見てもらうなら、下書きだけでなく公開直前セットまで作る方が楽だった
コメント