Claude Codeで全業務を1リポジトリに一元管理する作業基盤の作り方

仕事の素材が散らばっていると、AIは手伝いきれない

ども！Claude Code と毎日仕事している龍ちゃんです。

調査メモはNotion、コードはGit、ブログの下書きはGoogle Docs、スライドはまた別のツール……仕事の素材って、気づくとあちこちに散らばってませんか。

地味につらいのが「AIに手伝ってもらいにくい」こと。せっかく Claude Code を使っていても、調査メモが別の場所にあると「先月の調査をもとに、このコードのことを記事にして」が一発で通らない。毎回こっちが文脈を運ぶ羽目になります。

で、たどり着いた答えはすごくシンプルで。日常のどんなタスクも、1つのリポジトリの中で進める。調査も検証も実装もブログも、全部そこでやる。それだけです。

これをやると、いいことが2つあって。1つは、Claude Code が全部読んで横断して手伝ってくれること。もう1つがやった作業が消えずに積み上がることなんですよね。ここで言う”積み上がる”は、一度やった調査や検証が、後の別のタスクから参照されて使い回せる状態のことです。バラバラのツールでやると、終わったタスクはそのまま埋もれて消える（うっすらとした記憶で探すのも大変）。でもリポジトリの中で進めれば、調査も検証も全部残って、次の仕事の土台になる。点だった作業が、線でつながっていく感覚です。

この記事では、その「全部1リポジトリ」をどう組んで、どういう連鎖が起きて、どこから始めればいいかを順に話します。

全業務を1つのリポジトリに集約している

まず、どんなエンジニアにも共通する話をします。コードを書く人なら、調査も検証も実装も同じリポジトリに置くだけで、「なんでこの設計にしたんだっけ」と悩む時間が減ります。コードの隣に検証メモが残っているし、「あの調査どこだっけ」と探し回らなくていい。仕事の種類は関係ないんですよね。

僕の場合は、さらに発信活動も業務の一部に入っているので、ブログやセミナーも同じ場所に置いています。会社としてテックブログとYouTubeチャンネルを運営していて、情報発信も仕事のうちになっているんですよね。だから開発・調査・発信が全部同じ業務として同じ場所にある、というのが実情です。

ディレクトリがそのまま業務の地図になっていて、こんな感じです。

リポジトリ/
├── docs/
│   ├── research/      # 調査・リサーチ
│   ├── experiment/    # 検証・実験
│   ├── article/       # ブログ記事の下書き
│   ├── seminar/       # セミナー企画・登壇資料
│   └── data/          # 業務まわりのデータ置き場
│       ├── blog/      #   公開ブログのスクレイピング
│       ├── pv/        #   月次PVデータ
│       ├── x-post/    #   X（旧Twitter）投稿
│       ├── youtube/   #   YouTube用の原稿
│       └── …          #   チラシ・登壇資料なども
└── application/       # 開発・ツール実装

会議録や Slack のやり取りには、社外秘や他のメンバーの発言（＝第三者の個人情報）が混ざりがちです。リポジトリを公開・共有・画面共有する場面で一緒に漏れる導線になるので、そういうものは別管理にするか .gitignore に入れる、保存自体も所属組織のポリシーに沿う、を前提にしてください。
ここで大事にしているのは、何をリポジトリに入れるか（＝AIに読ませるか）は人間が判断しているということです。デリケートな情報は、そもそもリポジトリに置かない＝AIにも渡さない。AIに自動で何でも食わせるのではなく、「これは入れてよい素材か」を人の目で一段かませる。僕も「出していい素材」と「社外秘」は置き場を分けていて、後者はそもそもこの仕組みに乗せません。

整理されていること自体が目的じゃないんですよね。「ここに全部ある」という状態が、後の仕事の進めやすさを変えます。次のセクションで具体的に話しますね。

点と点が、線でつながった

「全部1つのリポジトリに入れた」結果、一番大きく変わったのは「知識の使われ方」ですね。

以前は、調査した内容は調査ノートの中で完結していました。記事を書くときは記事フォルダだけ見て、コードを書くときはコードだけ触って、という感じで。それぞれの仕事は「点」として存在していたんですよね。

それが1つのリポジトリに集まると、調査→検証→実装→発信という流れが、ファイルのパスをたどるだけで全部追えるようになりました。

docs/research/ での調査が起点になって、そこから docs/experiment/ での検証に進み、検証結果は2方向に分岐します。エンジニアとしての成果は application/ の実装へ、発信としての成果は docs/article/ のブログ記事やセミナー資料へ。さらにブログが公開されると、PV分析の結果を見て次の調査テーマが決まっていく。こうして、バラバラだった点が線でつながって、ぐるっと循環するようになります。

この「つながり」こそが、僕がやりたかったことの正体だと思っているんです。点のままだと、作業が終わった瞬間に埋もれていく。でも線でつながっていれば、どこかの作業が後の作業の土台になる。調査メモが記事を変え、記事のPVが次の調査を決め、検証の経緯が実装の判断根拠になる。やった仕事が消えずに積み上がっていく、という感覚です。

線でつながっている実例

コードの前に、検証の計画をドキュメントで残す

検証や実験をするとき、僕はいきなりコードから書き始めないんですよね。先に「何を確かめたいのか」「どういう手順でやるのか」「どんな仮説を置くのか」をドキュメントに書いて、整理してから実装に入ります。いわゆるドキュメント駆動ですね。

たとえば最近やった MCP サーバーの検証だと、「返ってくるデータ量やツール定義の書き方が、LLM のトークン消費にどう効くか」という仮説と検証シナリオを先にドキュメントで組み立てて、それから実際に動かすコードを書きました。計画のドキュメントと、それを動かすコードが、同じリポジトリに並んで残ります。

これの何がいいかというと、後から「なんでこの設計にしたんだっけ」となったとき、計画の方を見れば、どんな仮説を立てて、測ってみてどうで、だからこうした、という経緯が全部たどれるんですよね。判断の理由が実装の隣に残っている状態です。お恥ずかしい話、以前はこういう計画や経緯メモは別のドキュメントツールに書いて、そのうち参照されなくなる流れだったので。リポジトリで完結させると「消えない判断根拠」として残り続ける。後で設計を見直すとき、隣のドキュメントを開けば理由がそのまま残っている状態です。

さらに、検証して出た結果（レポート）も同じ場所に書き残しておくと、もっと変わります。計画 → 実装 → 検証結果までが1か所にそろうので、その結果をそのままブログやセミナーのネタに使うところまで、一本の線で通るんですよね。「検証したけど、結果どこ行ったっけ」と一回一回情報を探す手間がなくなって、やった検証がそのまま発信の素材になります。

PVの傾向から次のネタが決まる

「隣のネタを拾う」という感覚に近いんですが。Agent Skills まわりの記事が伸びていたので、じゃあ隣のトピックである Issue 操作のネタを調査して記事にしよう、という判断をしたことがありました。PV分析→調査→記事化という一連の流れが、同じリポジトリで完結したんですよね。分析結果のメモと記事のドラフトが同じ場所にあると、「この流れで次は何をすべきか」をAIと一緒に考えやすいし、読んだ分析が次の調査へ自然につながっていく。過去のデータが次の仕事の起点になる、というのが一番わかりやすい実例だと思います。

PVのみを意識してブログを出しているわけではありませんが、データも身近にあることで投稿ブログの分析などがブログ執筆のプロセスに入ってきて、執筆活動の質に少しだけマーケティング的視点を入れることができるようになってきました。

この記事自身が一番の実例

こちらのブログでもデータを集約したことでの恩恵にふんだんにあやかっています。

Karpathy の LLM Wiki や みのるんさんの「Claude Codeですべての日常業務を爆速化しよう」 がモノレポや知識集約まわりで同じ方向のことを書いているのを調査ノートで確認していたので、「集約しようというだけじゃなく、集約すると連鎖が起きるという方向で書こう」と記事の角度を変えられました。巨人たちが同じことを言っているのは、独自の発見というよりむしろ裏付けですね。あくまで参考にさせてもらっている立場です。それでも、調査メモが記事の角度を変えたというのは、先行事例の調べものがそのまま次の判断材料になった一例です。（ちなみに先人たちは巨人って表現をしてきたのはAIですww）

なお、検証から記事化するフローの詳細は「検証→記事化で知見を資産化する」でまとめています。”知見を資産化”という考え方はこの記事が先行しているので、合わせてどうぞ。スライドも application/slides に置いているので、記事の内容をそのまま流用してセミナー資料も作れます。

過去記事を下敷きにして情報補完する

ブログを書いていると「この話、前に別の記事で書いたな。リンク貼っておこう」という場面がよくあります。でも、過去記事を探して、URLを確認して、リンクを貼って……というのを毎回手作業でやるの、地味につらいんですよね。過去記事も同じリポジトリにあれば、Claude が「その話はこの記事で書いてますよ」と拾って、リンク候補まで出してくれる。手で探していたリンク貼りが要らなくなります。

もう一つ、これも小さいけど助かるのが、企画の重複を防げることです。「これ書こう」と思って調べ始めたら、実は企画レベルで前に着手していた、みたいなことがたまにあるんですよね。過去の記事も企画メモも全部同じ場所にあると、書き始める前に「似たやつ、もうありますよ」とAIが気づいてくれる。書き上げてから「これ前にやってたやつだ」と気づく事故が減ります。

どちらも、過去の仕事が文脈ごと同じ場所に残っているから成り立つ話で。別のツールに書き散らしていたら、そもそも探し出せなかったと思います。

始め方は1本のファイルから

一気に全業務を移す必要はないんですよね。おすすめは「まずリポジトリを1つ作る」こと。それだけです。

次に、docs/research/ みたいなディレクトリを切って、/research で調査させた結果か、手元の調査メモを1本だけ置く。その1本を起点に、記事やコードから参照が伸びていきます。最初から整えようとしなくていいんですよね。「置き場を1つ決めて1本置く → そこから参照が伸びる」という流れが最小の始め方で、リポジトリに仕事が溜まるほど、使い回せるものが増えていきます。

調査の品質を上げる /research の使い方は「Claude Codeの調査品質を /research で上げる」と「調査→構造化→注入」で紹介しているので、調査の置き場から始めたい方はそちらもどうぞ。

使ってみての感想

使い始めて一番変わったのは「終わった仕事が消えずに残っていく」感覚ですね。以前は、調査やメモは「その仕事のためだけのもの」で、終わったら参照されなくなっていくことが多かったんです。でも全部1つのリポジトリに入れると、終わった仕事が次の仕事の土台になっていく。同じ時間をかけた作業が、使い捨てじゃなくて積み上がっていく感じがあります。

Second Brain 的な考え方とも近いんですが、ちょっと違うのは、僕にとっての「外部記憶」はむしろブログの方なんですよね（笑）。一度書いて公開した話は、もう頭で覚えておかなくても「あの記事に書いてある」で済む。リポジトリはその手前にある、書く前の素材が全部そろっている場所、というイメージです。自分が思い出せなくても Claude が横断して引き出してくれるので、記憶の代替というよりは仕事の土台になっている感覚ですね。「積み上がる」というのが、いちばんしっくりくる言葉です。

あと、進捗管理やタスク管理も同じリポジトリで回しているんですが、git の履歴がそのままタスクの棚卸しになる、という話は少し長くなるので次の記事に書こうと思っています。近日公開予定です。

今回関連する記事はこちらです。

• 調査品質・/research の使い方
• 調査→構造化→AIへの注入
• 検証→記事化で知見を資産化
• 製品モノレポとの違い（CLAUDE.md活用）
• 履歴でタスクを棚卸しする（次記事・近日公開予定）

ほなまた〜