スキップしてメイン コンテンツに移動

Claude Codeプロジェクトを効率化する:dotclaude-templateの設計思想

Claude Codeを使った開発で、プロジェクトが複雑になるにつれて課題を感じていませんか?そんな課題を解決するために、dotclaude-templateを開発しました。

課題:複雑なプロジェクトでのAI活用の限界

Claude Codeは単一の対話で多様なタスクを処理できる強力なツールです。しかし、複雑なプロジェクトでは以下の課題が発生します。

コンテキストの肥大化

プロジェクトが大きくなるにつれ、すべての知識を一度に保持しようとすると焦点がぼやけます。「何でもできる」が逆に「何をすべきか」を不明確にしてしまう。

品質のばらつき

専門性が必要な領域(API設計、テスト設計、デバッグ戦略など)で、一般的な対応になりがちです。

セッション間のコンテキスト消失

作業を中断して再開すると、前回の状態や未完了タスクを思い出すのに時間がかかります。

dotclaude-templateとは

Claude Codeプロジェクトのための.claude/ディレクトリテンプレートです。エージェント分離コマンド定義により、複雑なプロジェクトでも一貫性のある開発体験を実現します。

.claude/
├── agents/           # 専門エージェント定義
│   ├── project-manager.md
│   ├── implementer.md
│   ├── test-runner.md
│   └── debugger.md
└── commands/         # カスタムコマンド定義
    ├── session-start.md
    └── session-end.md

設計思想:専門エージェントによる責務分離

基本4エージェント

  • project-manager: 計画策定・タスク分解・他エージェントへの委譲
  • implementer: コード実装・リファクタリング
  • test-runner: テスト実行・結果分析・カバレッジ管理
  • debugger: 根本原因分析・仮説検証・修正提案

連携パターン

エージェント間の協働を明文化することで、一貫した品質を実現します。

例えば、新機能の実装フローは:

  1. project-managerが要求を分析し、実装計画を策定
  2. implementerに実装を委譲
  3. 実装完了後、test-runnerがテスト実行
  4. 失敗時はdebuggerが根本原因を分析
  5. project-managerがユーザーに報告

コマンドによるワークフロー標準化

session-start / session-end

セッション管理コマンドにより、コンテキストの永続化を実現します。

/session-start:セッションID生成、前回セッションの状態復元、環境情報の確認、未完了タスクの把握

/session-end:作業内容の記録、未完了タスクの明確化、次回アクションの整理

これにより、作業を中断しても次回スムーズに再開できます。

Serena Memoryによるコンテキスト永続化(推奨)

セッション間のコンテキスト保存には、SerenaのMemory機能を強く推奨します。

Serena Memoryを使う理由

  • 会話リセットに強い: ファイルベースの保存と異なり、MCPサーバー経由で確実に永続化
  • 構造化データ: セッションID、未完了タスク、次回アクションを整理して保存
  • シームレスな復元: /session-startで自動的に前回の状態を復元
# Serena Memoryに保存される内容の例

## Last Session
- Session ID: 20260125_143052
- End Time: 2026-01-25 17:30:00

## Incomplete Tasks
- [ ] 機能Aの実装
- [ ] テストの追加

## Next Actions
1. 機能Aの実装を完了
2. コードレビュー対応

Serenaが利用可能な環境では、セットアップ時にSerena Memoryの使用が自動的に設定されます。

ドメイン固有エージェントの追加

基本4エージェントに加え、プロジェクト固有の専門家を追加できます。

例:Webアプリケーション

agents/
├── project-manager.md
├── frontend-specialist.md       # React/Vue実装
├── backend-specialist.md        # API実装
├── database-specialist.md       # スキーマ設計
├── test-runner.md
└── debugger.md

例:最適化プロジェクト

agents/
├── project-manager.md
├── python-specialist.md
├── test-runner.md
├── debugger.md
├── optimization-specialist.md   # 最適化問題の定式化
├── data-validator.md            # 入力データ検証
└── result-analyzer.md           # 結果分析・可視化

使い方

方法1:Claude Codeで自動セットアップ

Claude Codeで以下のように指示するだけ:

このリポジトリを読んで、私のプロジェクトに.claude/環境を構築して
https://github.com/manabelab/dotclaude-template

Claude Codeがプロジェクトの特性をヒアリングし、適切なエージェントとコマンドを生成します。

ヒアリング項目

  • 主要言語(Python / TypeScript / Go など)
  • ドメイン(Web / データ分析 / 最適化など)
  • テストフレームワーク
  • パッケージマネージャー
  • Serena MCPサーバーの有無
  • ドキュメント言語(英語 / 日本語 / 中国語 / 韓国語)

方法2:手動コピー

  1. templates/ディレクトリの内容を.claude/にコピー
  2. プロジェクトに合わせてカスタマイズ

多言語対応

セットアップ時に言語を選択することで、エージェント・コマンド定義を希望の言語で生成できます:

  • English
  • 日本語
  • 中文
  • 한국어

まとめ

dotclaude-templateは、Claude Codeを使った開発をより構造化・効率化するためのテンプレートです。エージェント分離とコマンド定義により、複雑なプロジェクトでも一貫した開発体験を提供します。

ドキュメント:

ぜひお試しください。フィードバックやコントリビューションも歓迎します。

コメント

このブログの人気の投稿

Sourcetreeを使って、特定のブランチやタグをローカルに再現する方法 - フェッチ(fetch)を使おう -

今や、プログラミング開発に欠かせない存在となったGit。上司や同僚から「修正版をブランチ"devlop"にプッシュしたから、それを反映させてね」「安定版はタグ”v1.2”だから、よろしくね」と言われることもあるでしょう。その時に「どうやってブランチやタグって変えたらいいかわからない」「そもそも言われたブランチやタグが見当たらないんだけど…」となったら、とても困ってしまいます。そんなときにどうしたらいいか、本記事では Sourcetree を使用している環境を想定して、おすすめの手順を紹介します。環境によって具体的な操作は異なるものの、手順自体は一緒です。基本的には、 フェッチ(fetch)をしてリモートリポジトリをちゃんと確認 すればよいのです。 1. コミットしていないファイルをなくそう まず、Sourcetreeのコミット一覧に「コミットされていない変更があります」とあるかどうか確認します(下記図赤下線参照)。「コミット」の箇所に青マークでコミットされてないファイル数も表示されます(下記図赤枠参照)。その変更をコミットするか、破棄するかを行い、コミットされていない変更がない、きれいな状態にしましょう。そうしないと、後の作業中にエラー等が発生して進まなくなってしまいます。 2. フェッチしよう フェッチとは、 リモートリポジトリの最新の履歴の取得だけを行う 操作です。これによって、自分から見えていなかったブランチ・タグが見えるようになります。ブランチへのマージが伴うプッシュやプルと異なり、単に履歴を取得するだけなので、意図しないコミットが発生しません。安心して実施しましょう。Sourcetreeでは下記図赤枠部分をクリックすれば、フェッチを行うことができます。 その際出てくるポップアップで「すべてのリモートからフェッチ」「全てのタグを取得」をチェックしてください(下図赤下線参照)。 3. 目的のブランチ・タグを見つけよう 目的のブランチ・タグを見つけるのに便利なのが、Sourcetreeの左側領域にある「ブランチ」「タグ」「リモート」「スタッシュ」です。目的のブランチを探したい場合は「リモート」をクリックして現れる「origin」をさらにクリックしましょう。これでリモート上にあるブランチの一覧を見ることができます。タグの場合は「タグ」をクリック...

SourcetreeでGitHubのプライベートリポジトリをクローンする

Sourcetree は、初心者でも操作しやすいgitのGUIツールです。基本無料のソフトなので、あらゆる人が導入・利用しやすいという利点を持ちます。ですが、GitHubで非公開、つまりプライベートのリポジトリを取り扱う場合には、初期設定に一工夫が必要です。 本記事で紹介する設定の流れは以下の通りです。前提として、1)GitHubのアカウントとプライベートリポジトリを既に所有しているが、2)Sourcetreeを自身のPCにまだインストールしていない状態を想定しています。 GitHubのPersonal access tokenを作成する Sourcetreeを自身のPCにインストールする SourcetreeにGitHubのアカウントを登録する プライベートリポジトリをクローンする 今回はPersonal access tokenという手法を用います。秘密鍵や公開鍵が必要なSSH接続とは異なり、アカウント名とパスワードのみで認証できます。そのため、アカウント管理がより重要となりますので、 2段階認証 でより強力なアカウント保護をおこなうことをお勧めします。また、本記事で紹介するのはWindowsでの利用です。Macでもほぼ同じ流れになるかと思いますが、試してはいませんのでご了承ください。 1. GitHubのPersonal access tokenを作成する GitHubのPersonal access tokenとは、GitHub API またはコマンドラインを使用するときに GitHub への認証でパスワードの代わりに使用できる機能です。このトークンを自身のGitHubアカウントで作成することで、Sourcetreeからプライベートリポジトリにアクセスすることができるようになります。具体的な作り方は下記のGitHub公式ページををご参考ください。 Personal access tokenの作成方法: https://docs.github.com/ja/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token ポイントは手順8に書かれているS ...

GitHubのプライベートリポジトリからクローンできてもプッシュできないときの対処法 - Write権限の有無を確認しよう -

 以前、 SourceTreeを使って、GitHubのプライベートリポジトリにアクセスする方法 を記事にしました。その際、プライベートリポジトリからクローンできても、プッシュできない!という現象に遭遇するときがあります。下記のように、”そんなリポジトリは存在しないよ”というエラーが表示されます。 remote: Repository not found. もし、そのリポジトリがOrganaizationに属するものならば、 あなたのアカウントの権限が”Read”のみで、”Write”になっていない 可能性があります。権限に関してOrganaizationの管理者に確認してもらいましょう。 管理者がどういうルールで権限を決定しているのかによって、対応が変わるかと思います。一番手っ取り早い対応は、全てのメンバーのデフォルト権限を”Write”に変えてしまえばよいでしょう。Organaizationのページの右上にある「Settings」をクリックし、左に表示されるメニューから「Member privileges」を選択します。すると、左下のような画面が表示されますので、赤枠で囲っている「Base permissions」のプルダウン部分を"Write"に変更してください。 その他に、リポジトリ毎にアクセスできるメンバーを管理したい場合もあるかと思います。その際にはリポジトリの「Settings」→「Manage access」を選択し、設定等を変更してください。