T50｜CodexとClaude Codeを毎日触って気づいた、使い方よりも「働く場所」を整える理由

AIエージェントを毎日使っていて、こんな経験はありませんか。

頼んだAIは、どうも動きが冴えず、よけいな手直しが増えていく。
自分も、いざ作業に取りかかろうとして、なぜかパッと動き出せない。

でも、その原因はAIの賢さではありません。
AIが働く「場所」が、整っていないからでした。

小さな違和感が、積み重なっていた

きっかけは、ごく小さな違和感でした。

7月11日。VS Codeで新しいセッションを立ち上げると、なぜか毎回プランモードで始まる。デフォルトで立ち上がるよう設定したはずなのに、効いていませんでした。調べてみると、意外な真犯人。
違う意味の設定が2箇所に分かれていて、片方がもう片方を上書きしていたのです。

この「設定したつもりが効かない」という感覚は、その後の1週間、形を変えて何度も現れました。ルールは書いたのに読まれない。引き継ぎメモは役目を終えても消えない。完成品と作業の残骸が、いつのまにか同じ場所に散らかっている。

そこで発想が変わりました。AIに「何をやらせるか」を考える前に、AIが「どこで、どう働くか」を先に決める必要がある、と。

賢いAIを用意することと、AIが働ける場所を用意することは、違います。

この記事は、2026年7月11日から19日までの約1週間で、その「土台」を整えた記録です。土台と呼んでいるのは、大きく3つ。働く場所を決める。散らかりの逃がし先を決める。壊れず腐らず回り続ける形にする。
そして最後に、その判断を言葉にして残す。順番に見ていきます。

働く場所を決める。成果物と「散らかり」を、同じ場所に混ぜない

まず、場所です。

これまでOneDriveに、番号を振ったフォルダを何年もかけて溜めてきました。最初は、それをそのままAIの作業場にしようとしました。でも、ここで最初のつまずきです。全部を一律に「AIプロジェクト」にしようとすると、過去データや完成物を置いた保管庫と、日々の作業場が同じ場所で混ざってしまいます。

だから、フォルダを動かす前に3種類へ仕分けるルールにしました。保管庫か、すでにAI作業スペースか、その混在か。 どれに当たるかで扱いを変えます。

もう一つ、大事な分離があります。AIに作業させると、完成物のほかに大量の「散らかり」が出ます。依存環境、キャッシュ、一時画像、展開したファイル。これをOneDriveの中に吐き出すと、判断や会話や成果物を置いておきたい場所が、作業のゴミで汚れていきます。

スマホの写真でいえば、残したい1枚と試し撮りを、同じフォルダに撮りためていくようなものです。どれも同じ写真だから、あとで見返すと、どれが本番だったか分からなくなる。

そこで、置き場所を分けました。判断と成果物はOneDriveへ。重い処理の実行と、そこから出る散らかりは、PCローカルの一時置き場（scratch）へ逃がします。「成果物」と「散らかり」を、最初から別の住所に振り分けるわけです。

実際に、「26_探究指導案」という教材のプロジェクトで試しました。移動の前に仕分けてみると、OneDriveに残す成果物は373ファイル・約300MB。ローカルへ逃がした散らかりは、1408ファイル・約49MB。容量は小さくても、ファイル数でいえば散らかりのほうが4倍近く多かったのです。

あなたのAI作業フォルダは、成果物と「作業のゴミ」が、同じ場所に積もっていないでしょうか。

土台づくりで、私がとくに気をつけた2つのこと

場所を決めれば終わり、ではありませんでした。作りながら、分かったことがあります。土台は、放っておくと2つの形でダメになります。

1つ目は、壊れる。

土台を整えるということは、これまで思い思いの場所で作業していたフォルダを、あるべき場所へ置き直すことでもありました。7月15日と18日、フォルダ名の変更と移動をしています。

もちろん、動かせば設定に書いたパス参照は切れます。そこは分かっていました。肝心なのは、その先です。動かす前に「この名前を参照しているのはどこか」を一括で検索して洗い出し、まとめて直しました。これをやらないと、動かしたあとに「どこかで参照が切れている」ことに気づかず、作業が止まります。

2つ目は、腐る。

長い作業の区切りで、引き継ぎメモ（handoff）を作ります。ところがこれが、役目を終えても消えずに残る。実際、数日前に作ったメモが、全部の作業が終わったあとも放置されていました。そこで、「作る → 次のセッションで読んで再開する → 用が済んだら消す」まで、最後までやりきる仕組みにしました。

土台は、作りっぱなしにすると壊れて腐ります。維持まで含めて、はじめて設計と言えるのです。

最後にやったのは、判断を「言葉」にして残すこと

この1週間、判断はすべてその場の対話から生まれました。混ぜない。分ける。動かす前に洗い出す。消す前に中身を見る。どれも、散発的なやり取りの中で下した判断です。

最後にやったのは、こうした判断を一枚の「運用方針」という正本に束ねることでした。

じつは、方針のたたき台そのものは最初にありました。自分の考えをChatGPTにぶつけながら整理した、最初の版です。でも、それが完成形ではありませんでした。CodexやClaude Codeと相談しながら作業を進めるほど、想定が現実と食い違い、何度も改訂が必要になったのです。

面白かったのは、その順序です。完成した方針が先にあって、それに従ったのではありません。たたき台を実践にぶつけ、直しては、またぶつける。そのうちに、方針のほうが地に足のついた形へ育っていきました。1週間の実践を経たからこそ、絵に描いた理想ではなく、使えるルールになったのです。

環境整備の最後の仕上げは、下した判断そのものを、次に使える言葉にして残すことでした。

Codexでも、Claude Codeでも、土台は同じだった

今回の土台づくりでは、CodexとClaude Codeの両方を併用しました。場所の設計も、環境の運用整備も、2つのAIを行き来しながら進めた作業です。

でも、やっていたことは同じでした。

どちらのAIも、まず働く場所を決め、散らかりを逃がし、壊れず腐らない形にして、最後に判断を言葉にして残す。この順番は、どのAIを使うかに関係なく効きます。エージェントの種類が違っても、働くための土台は共通だったのです。

新しいAIツールを触るとき、私たちはつい「何ができるか」から入ります。でも、土台を置き去りにして新しいことばかり追いかけていると、いつか必ず手が止まります。

次にAIに何かを頼んで作業が止まったとき、それはAIのせいでしょうか。それとも、まだ整っていない「場所」のせいでしょうか。

土台を先に整える。まずはそこからやり直しました。

人生の限りある時間を大切に。シンパクト和 でした。
最後までお読みいただき、ありがとうございます。スキやコメントをいただけると励みになります。