作業ログ

Claude Codeに手探りで聞きながらAIデスクの土台を作った日

mano
Claude Codeに手探りで聞きながらAIデスクの土台を作った日

「AIデスクを作った」って言うと、なんかちゃんと設計図があってその通りに組み立てたみたいに聞こえるんだけど、実際はだいぶ違う。

この日やったことを並べてみると、フォルダを分けたり、削除のルールを決めたり、それっぽく見えることは確かにやってる。でもその一つ一つの判断が、最初から狙って出てきたものはほとんどない。

知識がゼロの状態から、目の前のClaude(AI)に聞いて、返ってきた案を見てまた聞いて、を繰り返しただけだ。VSCodeの拡張機能でClaude Codeと話していたはずなのに、気づいたらターミナル版のCLIまで入れていた。狙って入れたというより、必要に迫られて増えていった感じがする。

この記録は、後から振り返って「あの日はこう考えて動いていた」というのを自分用に残すためのものでもある。だから答えを出して締めくくる感じにはならないと思う。むしろ、この日決めたことのうち半分くらいは、手探りのまま今も転がっている。

VSCode拡張とターミナルCLIを使い分けるAIデスク構築の第一歩

Claude Codeの2枚使い構成

VSCode拡張機能でClaudeと対話しながら方針を練り、ターミナルCLIで実際のコード処理を実行する2面体制を、この日のうちに組んだ。

対話用と実行用でウィンドウを分ける判断

最初はVSCodeの拡張機能だけで十分だと思っていた。会話しながらコードを書いてもらえるし、画面もひとつで済む。でもファイルをまとめて動かしたり、コマンドを何度も打ち直したりする作業になってくると、拡張のチャット欄だとどうにも窮屈に感じてきた。

こまる
こまる

チャットの画面ひとつでよくない?なんでターミナルまで増やしたの?

mano
mano

考える時と手を動かす時で、画面ごと分けたほうが頭も切り替わる感じがしたんだよね

こまる
こまる

へえ、気分の問題ってこと?

mano
mano

気分もあるし、動かしてる最中に横で相談できるのも大きいかも

対話しながら方針を練るならVSCode拡張、作業をガリガリ回すならターミナルのCLI。この分岐に自分で気づいたのは、実際に両方を並べて動かしてみてからだった。Claude Code(Claude Codeとは?コードが書けない人でも業務を自動化できる理由と使い方・料金を徹底解説にまとめてある)自体、この日はまだ使い方を手探りしている状態で、こういう使い分けがあること自体を知らなかった。

wingetでのGit導入とバックアップ用リポジトリの作成

ターミナルでの作業を始めようとしたら、そもそもGitが入っていないことに気づいた。wingetで導入して、GitHub側でプライベートリポジトリを作成。VSCode側は既にGitHubへサインイン済みだったので、そこは思ったよりすんなり繋がった。

ポイント

AIデスク全体をリポジトリにしておけば、何かあってもGitHubに履歴が残る安心感がある

司令塔と実作業を分離するAIデスク フォルダ構成の設計

AIデスクの階層構造

全体の司令塔機能をルート直下にまとめ、個別の開発コードはprojects/内に隔離して、影響範囲を切り分けた。

ルート直下に司令塔機能を配置する

複数のプロジェクトを同時に見ていく前提だったので、どこかに全体の司令塔がいると考えた。ルート直下に共通ルールをまとめて、各プロジェクトのコードそのものはそこに置かない、という役割分担をこの時点で決めた。

ChatGPTから「knowledge・templates・projectsに分けたらどうか」という提案をもらっていて、それをレビューする形で採用した。CLAUDE.mdが肥大化しないこと、Knowledgeは追記じゃなく更新していくこと、あたりが良さそうだったので取り入れて、命名は将来のOS移行を見据えて小文字に補正した。

projects配下に実際のコード領域を隔離する

ルートに全部書いていくと、そのうち収拾がつかなくなるだろうという予感があった。ルートに書くとプロジェクト間の境目が曖昧になるけど、projects配下に分ければ、あるプロジェクトの変更が別のプロジェクトに影響することもない。

セバス
セバス

司令塔と実作業を分けておくと、後から人が増えても迷わずに済みますね

こまる
こまる

でもまだ一人で使ってるんでしょ?

セバス
セバス

ええ、今は先回りの意味合いが強いです

ファイルを即座に削除せず.dustboxに退避させるダストボックス方式

ダストボックス方式のデータ保護

誤削除のリスクを防ぎ記録を残すため、ファイルを直接消さず.dustbox/へ30日間保管する絶対ルールを、この日決めた。

経営者としての直感と証拠維持の意識

このルールだけ、他と少し出てきかたが違う。フォルダ構成やOS対応のルールは、必要性を考えてから決めた感じがあるんだけど、これは先に「消したくない」という感覚があって、理屈は後から追いついてきた。

注意点

ファイルを直接削除すると、間違いだったと気づいた時にはもう遅い

なんでそこまで消すことに抵抗があったのか、自分の中でも分析しきれていない部分がある。前の仕事の経験からくるものなのか、単に慎重すぎるだけなのか。証拠を残しておきたいという感覚が先にあって、ダストボックス方式という形はその後からついてきた、というのが実際のところだ。

30日経過後に自動削除するルールの明文化

直接ゴミ箱に捨てると証拠が残らないけど、.dustboxを経由させれば少なくとも30日間は追跡できる。ここは判断基準として割とはっきりしていて、削除が必要になったらまず.dustboxへ移し、タイムスタンプ付きのフォルダに退避させる、というルールをCLAUDE.mdに書いた。30日経ったら完全に消す、というところまでは決めたけど、実際にその期限が来た時どう運用するかはこれから試していくことになる。

Windows Mac 開発環境の違いを吸収する共通ルール

OS非依存の共通開発ルール

将来的なMacへの環境移行を想定し、絶対パスの排除や改行コードLF統一などOS差分に強い設定を早めに組み込んだ。

絶対パス禁止と改行コードLFへの統一

D:\〜のような絶対パスで書いてしまうとWindowsでは動くけど、Macに移った瞬間に壊れる。だから相対パスで書く、というのをルールにした。改行コードもWindows側でCRLFになりがちなので、LFに統一しておくことにした。

大文字小文字の差異に依存しないファイル命名

WindowsとMacでは、ファイル名の大文字・小文字に関する扱いが異なっている。不要なトラブルや混乱を避けるため、フォルダもファイル名もすべて小文字で統一する運用に落ち着いた。ここで失敗すると、将来環境を移行した瞬間にファイルが二重に増えたり参照が壊れたりする危険があるからだ。

自動コミットフックの適用をグローバルではなくプロジェクト単位に留めた理由

自動コミットフックの安全設計

全リポジトリに誤適用される事故を防ぐため、自動コミットフックはプロジェクトごとに安全装置付きで個別設定する方向にした。

全域適用による他リポジトリへの誤プッシュリスク

セッション終了時にTODOやChangelogを更新するルールを決めたあと、「まとめて、と言い忘れてPCを閉じたらどうする」という話になった。それで、応答が終わるたびに自動でGitHubへコミット・プッシュするStopフックを検討し始めた。

こまる
こまる

じゃあもう全部のプロジェクトに一気に適用しちゃえばいいんじゃない?

mano
mano

いや、それがちょっと怖くて。関係ないリポジトリまで巻き込んで自動プッシュされたら困るから

こまる
こまる

ああ、うっかり事故を防ぐってことね!

PC全体に一括で適用すると、無関係な他のリポジトリまで誤って自動プッシュしてしまうリスクがある。それならプロジェクト単位で個別に設定すれば、影響範囲をそのプロジェクトの中に限定できる。この分岐で、この日は範囲をプロジェクト単位に絞るところまでは決めた。

安全装置を組み込んだ個別フックの動作確認

Gitリポジトリでなければ何もしない、変更がなければ何もしない、pushに失敗しても処理を止めない。こういう安全装置を組み込んだフックを新規プロジェクトのテンプレートに入れて、一時的なリポジトリで実際に動くところまでは確認した。

注意点

安全装置なしの自動プッシュは、想定外のタイミングで意図しない変更を送ってしまう恐れがある

ただ、これを実際に普段使っているプロジェクトへ本格的に入れるかどうかは、この日はまだ決めていない。テストでは動いたけど、もっと安全装置を積んだほうがいいのか、このくらいで十分なのか、判断材料をもう少し集めていく必要がある。

発信素材をblogフォルダにストックする2段階運用

発信素材の2段階ストック運用

長時間対話による精度低下を防ぎつつ、セッション終了時にblog/フォルダへ素材を書き出す省力化の仕組みを、この日から回し始めた。

チャット継続によるコンテキストの精度低下対策

同じチャットを続けていくと、だんだん返答の精度が落ちてくる感覚があった。それなら都度ファイルに書き出しておけば、新しいセッションを始めても同じ材料から続きができる。ここは判断基準として分かりやすくて、覚えておきたいことはその場でファイルに落とす、というやり方に決めた。

セッション終了時に素材を溜めて後で記事化する手順

ポイント

素材は都度記事にしなくていい。溜めてから「ブログ用にまとめて」と指示すればまとめて処理できる

セッションが終わるたびに簡潔な素材をblog/へ溜めておいて、ある程度貯まったタイミングでまとめて記事化を指示する。都度書くのと、溜めてからまとめて書くのとでは、後者のほうが文脈の整理がしやすいと感じてこの手順にした。

完璧なノウハウではなく手探りの対話から生まれた設計思想

手探りの役割分担と継続的改善

最初から完成形を求めず、AIに質問を繰り返しながら分担方法を模索していく。この日はまだその途中だった。

何を作るかよりAIとの役割分担に悩んだ記録

この日は「何を作るか」より、「AIとどう役割分担するか」を延々考えていた。Claude Codeという道具自体、この日の自分にとってはまだ使い方が手探りの状態で、ターミナルとVSCodeの2枚使いという発想も、最初から狙って決めたわけじゃなくて、あれこれ試した末にたどり着いた形にすぎない。

セバス
セバス

今日は何か新しいものを作ったというより、道具の使い方を探っていた1日でしたね

mano
mano

うん、たぶんそう。何を作るかより先に、誰が何をやるかで悩んでた気がする

セバス
セバス

それは今後も続く問いかもしれません

答えを出さず手探りのまま運用を続ける姿勢

フォルダ構成もダストボックス方式もOS非依存のルールも、この日決めたことは一通り書き出したけど、どれも「これで完成」という手応えはなかった。自動コミットフックは範囲を絞ることまでは決めたけど、実際に導入するかはまだ決めていない。ダストボックス方式の底にある感覚も、言葉に落としきれていない部分が残っている。

それでも、何も分からない状態のままAIに聞き続けて、返ってきたものを試して、合わなければ聞き直す、というやり方自体は間違っていなかった気がする。今日組んだ土台がこの先どう変わっていくのか、それは今の自分にもまだ分からない。

こうして書き出すと結構な量をやったように見えるけど、その場ではひとつひとつ「これでいいのかな」と聞きながら決めていっただけだった。

ABOUT ME
mano
mano
全財産1.6万円から始めた人
2025/11/20 厄年なのかなんなのか色々起きて超どん底に。人生で初めて本気で起業しようと決意!元"ねらー"のサーチ力と持ち前の好奇心、今までの知識をフル活用して1,6万円から本気で起業を目指す!
記事URLをコピーしました