はじめに
先日、Claude Code のセッションをスマホから触る方法（Remote Control など）を調べる機会がありました。調べながらふと、自分の Claude Code の使い方を振り返りたくなりました。
そこでこの記事では、現時点の自分の Claude Code 運用の全体像を、雑記としていったん整理してみます。
運用の全体像
私の環境では Claude Code の居場所は2つあります。1つはローカルの Mac で動かす普通の Claude Code で、基本的に開発はここでやります。もう1つは Discord と繋いで常駐させている Claude Code で、相談ごとや記事まわりはこちらに投げることが多いです。
この2つは別々のセッションなので、そのままではお互いのことを知りません。
ローカルのClaude Code
主な使い所（開発）
個人開発はローカルのセッションで進めています。ブログ本体や自作ツールの開発、記事を書くための検証などです。プロジェクトのディレクトリで Claude Code を開いて、対話しながら作る、特筆することもないような使い方ですね。
プロジェクトごとのCLAUDE.md
各プロジェクトの CLAUDE.md に「現在の状況」という節を作って、最終更新日・完了したこと・次の一歩・関連リンクを書くようにしています。作業の区切りごとにこれを更新してコミットする、という運用です。
例えば、いま作りかけの自作ツールのプロジェクトだと、こんな内容が書いてあります。
## 現在の状況
- 最終更新: 2026-08-14
- 完了済み: プロジェクト作成 / AI-DLC v2 ハーネス導入 / GitHubリポジトリ作成・プッシュ
- 残り・次の一歩: /aidlc --doctor でセットアップ確認 → Ideation から開始
- 関連リソース: Discord #garage のスレッド「HTML共有ツールの自作」
試しながらやっていること
開発の進め方そのものもいろいろ試しながらやっています。最近だと grilling（実装前に AI から質問攻めにしてもらう壁打ち）や、AI-DLC（承認ゲート付きの開発ワークフロー）を試しつつ、という感じです。
また、Codex をセカンドオピニオンとして使っています。基本的な役割は読み取り専用のレビュー役で、Claude が書いたコードや設計判断を別のモデルの目で見てもらう形です。
Discordの常駐Claude Code
主な使い所（記事執筆・相談）
自宅の Mac で Claude Code のセッションを1本常駐させて、Discord のサーバーと繋いでいます。Discord にメッセージを送ると、常駐している Claude が反応して作業する、という形です。
以下の記事で紹介している Channels 機能を利用したものです。詳細なセッティング方法などはこちらをご覧ください。
いちばん使っているのは記事まわりで、ネタ出しの相談から下書き、レビュー、Qiita への投稿までの一連を Discord の会話で進めています。ほかには技術ニュースの深掘り、調べ物、ちょっとした依頼ごとなどです。
フォーラムスレッドでの文脈管理
Discord 側は、記事のネタ・開発案件・考えごとといった種類ごとにフォーラムチャンネルを分けて、1スレッド1文脈で運用しています。
スレッドごとに「何のためのスレッドで、いまどういう状態か」の台帳を持たせていて、Claude は返信の前にそれを確認します。
台帳の中身はチャンネルごとの表です。例えば、スクショの一番上に写っている #記事の種 の台帳は、いまこうなっています。1行目だけ実物をそのまま貼って、2行目以降は長いので省略します（内部リンクは伏せ字にしています）。
## #記事の種（1512843395532329062）
| スレッド名 | ID | 目的 | 状態 |
|-----------|-----|------|------|
| Ollamaからの乗り換え — LM Studio × llama.cpp × Strands | 1538371432751300739 | OllamaからLM Studio（MLX）+llama.cpp直へ乗り換える体験記ネタ。Strands Agentsからのローカルモデル利用（OpenAI互換API経由）とAgentCore連携も射程。#雑談 2026-08-16リュウキ発案「ollamaからいったん乗り換えようかな。ついでに記事化しよう」。動向調査レポート https://claude.ai/…（非公開） | 開始（2026-08-16作成）。環境=M4 MacBook Air 32GB / 乗り換え元=Ollama 0.32.5（gemma4:e4b/qwen3.5:9b/gpt-oss:20b、計29GB、速度比較用に残置→記事化後削除予定）。**検証完了（2026-08-16）**: LM Studio+llama.cpp導入済み・Strands連携両方成功（LlamaCppModel / OpenAIModel+base_url、gpt-oss-20Bでツールコール正答）・速度比較済み=llama.cpp直30.6 / LM Studio MLX30.2 / Ollama20.0 tok/s（ウォーム、旧Metalバックエンド）。gemma-4-E4B MLXもDL済み。検証プロジェクト ~/Desktop/work/local-llm-strands/ 作成済み（CLAUDE.mdが検証詳細の正）。残り=Ollama最新版でMLX再計測（続き検証ネタ）→記事叩き台→記事化後にOllama+旧モデル29GB削除。**2記事分割+見出し案提示済み（2026-08-16）**: ①【ローカルLLM】Ollamaから乗り換えてみた（はじめに/動作環境/Ollamaに何が起きているのか/セットアップ/速度比較/おわりに）②はリュウキ指示（2026-08-16）で「【Strands Agents】llama.cppサーバーでエージェントを動かす」に変更=過去記事「【Strands Agents】OllamaからローカルLLMを使ってみた」（qiita 600b20874a400741c20c）と被るため。LM Studio節は削除しllama.cpp主役（LlamaCppModel専用プロバイダの深掘り+過去Ollama版との違いが核）。修正版見出しOK（2026-08-16リュウキ「お願いします」）→ **①叩き台完成（2026-08-16、約3,300字、articles/drafts/20_執筆中/local-llm-ollama-migration.md、articlesコミットdcc35bf、board行追加済み、Artifact https://claude.ai/…（非公開） ）**。見出しは体言止めに微調整。残り=スクショ候補（LM Studioチャット画面/llama.cpp公式WebUI）→リュウキ確認→/review-blog。②Strands記事は見出し確定済み・未執筆。⏳リュウキ→①叩き台の確認 |
| AI-DLC v2を実際に回してみた — 体験ベースの記事 | 1538209349661360139 | AI-DLC v2を初めて実際に回した体験の記事化。…（略） | …（略） |
| フェリー予約エージェントLTの記事化 — Harness × Browser × Live View | 1534140490193043466 | 7/25 Lightning Sado 2026 の LT の記事化。…（略） | …（略） |
状態の列には切り分けの経緯や決めごとがどんどん追記されていくので、動きの多いスレッドほど長大になります。状態が動いたら Claude がその場で更新する運用です。
会話がどれだけ散らかっても、スレッドという単位で文脈が保たれるのが、チャットツールと相性のいいところだと思います。
読み込みのたびにコンテキストが膨らむのは今後の課題かと思っています。
memoryとknowledge
常駐側には記憶の置き場を分けて持たせています。あとでやることを覚えておくタスク台帳、私の好みや過去の経緯といった個人的なメモ、調査結果のような技術知見、の3種類です。
例えば、タスク台帳には「記事を本公開したら後片付けをする」のような約束ごと、個人的なメモには文体の好みやレビューで却下した指摘の記録、技術知見には「DynamoDB のベクトル検索対応を調べた結果」のような調査メモが入っています。
タスク台帳の中身はこんな形です。いつ登録したか、何をきっかけに動き出すか、何をするかをセットで書いておくと、登録したセッションが終わっていても常駐側が拾ってくれます。
### FinOps 記事の本公開後の後片付け
- 登録日: 2026-08-02
- トリガー: 私が「記事を本公開した」と言ってきたら
- 内容: 検証で作ったエージェントを削除 → 削除時の挙動を記事に一文追記して更新 → 下書きをアーカイブ
- 関連パス: articles/drafts/... / knowledge/aws-finops-agent.md
技術知見のほうは、カテゴリ-トピック.md という命名の Markdown ファイルが並んでいるだけのシンプルな構成です。
knowledge/
├── aws-agentcore-harness.md
├── aws-dynamodb-vector-search.md
├── llm-local-runtimes.md
└── web-duckdb-wasm-site-search.md
場所をまたいだコンテキストの共有
ローカルのセッションと Discord の常駐は別物なので、コンテキストの共有が問題になります。私の環境では、git 管理のファイルを共有メモリにすることで対応しています。
例えば、ローカルで進めている自作ツールについて Discord で「あれどうなってたっけ」と聞くと、常駐側はそのプロジェクトの CLAUDE.md の「現在の状況」と直近のコミットを読んでから答えてくれます。
逆に、Discord 側で記事のレビューや修正をした結果はその場でコミットされるので、あとで PC を開いたときには反映済みになっています。ファイル越しに状況を把握してから動く、プル型の同期ですね。
使い分けの軸
この振り返りのきっかけは Remote Control のようなセッション共有機能でした。どちらもスマホから Claude Code を使う話に見えて、「うちの Discord 常駐と何が違うんだろう」と思ったんですよね。
整理してみて感じたのは、軸は「作業の続きを自分が（Claude と相談しながら）するか、任せるか」だということです。セッション共有機能は同じ作業を別のデバイスから続けるもので、操作するのは自分です。
一方 Discord の常駐は、依頼を投げて報告を受け取る非同期の窓口で、作業をするのはエージェント側です。
どのデバイスから触るかではなく、自分が手を動かすか任せるかで考えると整理しやすいと思います。
課題と今後
冒頭のセッション共有機能（Remote Control・クラウドセッション）は、調べて把握した段階で、運用にはまだしっかり組み込んでいません。ここはおいおい整備していきたいです。
もう1つの気がかりは、常駐 Claude が自宅の MacBook に依存していることです。ちょっとしたミニPCを用意したり、クラウドとの併用をしてみたりなど上手いこと整えたいなと思っています。
おわりに
以上、自分の Claude Code 運用をいったん振り返ってみました。書き出してみると、派手な仕組みがあるわけではなくて、「状況をファイルに書いて git で共有する」という地味な習慣がベースになっていました。
同じように複数の場所で Claude Code を使っている方の参考になれば幸いです。
ありがとうございました。