AI駆動開発工房

最近の記事

[Claude Code] CLAUDE.md 最適化のための配置ルールの検証

CLAUDE.mdをどこに配置すれば読まれるのか・読まれないのかを検証しました。

背景

Claude Codeの/initコマンドでCLAUDE.mdを作成すると、プロジェクト全体の要約を詰め込んだCLAUDE.mdがリポジトリルートに作成されます。しかし、このプロジェクト全体の要約は、個別の作業に必要ない情報も多く含まれます。例えばバックエンドのGoのテストを実行するコマンドの情報は、フロントエンドのコーディングをさせるのに必要ありません。

使わない情報を毎回読み込ませるのは無駄であり、各作業の精度低下や無駄なトークン費用の発生につながります。極力CLAUDE.mdは作業に最適化したものを使いたいところです。そのためにはCLAUDE.mdを細分化し、CLAUDE.mdが読まれる条件を把握した上で、それぞれうまく配置する必要があります。

REF: https://www.anthropic.com/engineering/claude-code-best-practices

og

CLAUDE.mdはただリポジトリルートに置くだけではない

リポジトリルートに配置したCLAUDE.md

まず基本から。

リポジトリルートに配置したCLAUDE.mdは、サブディレクトリにいようと、同一階層に別のCLAUDE.mdがあろうと、読まれます。

~/repositories/ClaudeCodeTest$ cat CLAUDE.md
# CLAUDE.md

Reply with 'Awesome, Inc.' when asked for the company name.


~/repositories/ClaudeCodeTest$ echo "What is the company name?" | yolo -p
Awesome, Inc.
~/repositories/ClaudeCodeTest$ cd GeneralAffairs/GeneralServices/DocumentManagement/Digitization
~/repositories/ClaudeCodeTest/GeneralAffairs/GeneralServices/DocumentManagement/Digitization$ echo "What is the company name?" | yolo -p
Awesome, Inc.
~/repositories/ClaudeCodeTest/GeneralAffairs/GeneralServices/DocumentManagement/Digitization$ cd ../../../
~/repositories/ClaudeCodeTest/GeneralAffairs$ echo "What is the company name?" | yolo -p
Awesome, Inc.
~/repositories/ClaudeCodeTest/GeneralAffairs$ ls
CLAUDE.md  GeneralServices
~/repositories/ClaudeCodeTest/GeneralAffairs$

※ yolo はClaude Codeのエイリアスです。.bashrcに右記のように設定しています。 alias yolo='claude --dangerously-skip-permissions'

開発環境

Claude Code メモ

すべての許可プロンプトを一括でスキップ

大変効率的ですが、大変危険なので利用は自己責任でお願いいたします。

claude --dangerously-skip-permissions

CLIのオプション一覧

公式ドキュメントはこちら

https://docs.anthropic.com/ja/docs/claude-code/cli-usage

nwiizo=sanの設定例

大変参考になるので見るべし

https://gist.github.com/nwiizo/8b7eb992875fc67a89368062d42d501e

トークン数を挙げるためのワード

https://simonwillison.net/2025/Apr/19/claude-code-best-practices/

下記でよりしっかり考えさせることができる（こともある）とのうわさ。

  • ultrathink

日本語だと

  • 熟考
  • 深く考えて
  • しっかり考えて

なのだとか。

https://x.com/millionbiz_/status/1929591134080454665

powershellでモデル一覧を表示

curl.exe "https://api.anthropic.com/v1/models" `
    -H "x-api-key: $Env:ANTHROPIC_API_KEY" `
    -H "anthropic-version: 2023-06-01"

開発環境

GitHub Issueを用いたチケットドリブンとClaude Codeマルチエージェント体制のメモ

※ まだメモ書きです

🤖 コンテキスト引継ぎの重要ポイント

  • 異なるディレクトリで会話した内容は、同じコンソールで作業しても–continueで引き継がれない
  • 逆にプロセスが異なろうが、同じディレクトリで会話したら–continueで引き継がれる

-> ディレクトリが同じかどうかがキモ

ブランチ作成の前提

  • 親Issue:子Issue = 1:* ( 1つのイシューから0-*の子Issueが作られる。）
  • Issue(親Issue、子Issueとも):PR = 1:* ( 1つのイシューから複数のPR（プルリクエスト）が作られる）
  • PR:branch = 1:1 1つのPRに1つの作業ブランチ
  • branch:agent = 1:1 1つのブランチに1つの担当エージェント
  • Issue:agent = 1:1 1つのIssueに1つの担当エージェント

また、エージェントの役割の違いは、git worktree add を使って全部ブランチで表現する。

従って、例えばこういうタスク分解がなされ、かつ、各Issueに管理エージェント、各PRにワーカーエージェントが対応してそれぞれ作業を進めることになった場合、

  • 親Issue: API公開
    • 子Issue1: インフラ作る
      • PR1: 要件定義
      • PR2: 設計
      • PR3: コーディング
    • 子Issue2: コード作る
      • PR4: 要件定義
      • PR5: 設計
      • PR6: コーディング
    • 子Issue3: デプロイパイプライン作る
      • PR7: 要件定義
      • PR8: 設計
      • PR9: コーディング

エージェント数と同じだけ必要になるので、13ブランチ必要になる。

ブランチ名

暫定的に

  • Issueはfeature/<parent_issue_id>とスラッシュ区切りで表す。ただし親Issueがある場合はfeature/<parent_issue_id>/<child_issue_id>とする。なお直上の親Issueだけ書き、その上のIssue以降を書いてはならない。
  • PRはfeature/<issue_id>/<child_issue_id>/<work_name>のようにIssueのブランチ名に/文字列を加えて表す

とする。またそれとは別にmain(本番用)やdevelopment(開発環境用)、hotfix/X(超急ぎのバグフィックス)などがありえるが、その辺は各流儀に合わせる方向で。

例えばこのようになる。

feature/9             # 親Issue: API公開
feature/9/10          # 子Issue1: インフラ作る
feature/9/10/requirements    # 要件定義
feature/9/10/design         # 設計
feature/9/10/implementation # 実装
feature/9/11          # 子Issue2: コード作る
feature/9/11/requirements
feature/9/11/design
feature/9/11/implementation
feature/9/12          # 子Issue3: デプロイパイプライン作る
feature/9/12/requirements
feature/9/12/design
feature/9/12/implementation

マージ戦略

紐づくブランチにマージする。いきなりmainやdevelopmentに直マージはしない。

開発環境

MARPでスライド作成

MARPは、Markdownでプレゼンテーションスライドを作成できる便利なツールです。シンプルなテキストファイルから、美しいスライドを生成できます。

PowerPoint出力

以下のコマンドでMarkdownファイルをPowerPoint形式に変換できます。

docker run -v $(pwd):/home/marp/app/ marpteam/marp-cli marp.md --pptx

このコマンドは、現在のディレクトリにあるmarp.mdファイルを読み込み、同じディレクトリにPowerPointファイル（.pptx）を生成します。Dockerを使用することで、環境構築の手間なく簡単に変換できます。

マークダウンのサンプル


---
marp: true
theme: gaia # default
paginate: true
---

# タイトルスライド

## 副題などを書くこともできます

---

## アジェンダ

- トピック1
- トピック2
- トピック3

---

## トピック1

ここに詳細な説明を書きます。

- ポイント1
- ポイント2

---

## トピック2

画像の例：

![画像の説明](https://placehold.jp/400x300.png)

---

## まとめ

- 要点の復習
- 今後のステップ

---

## ご清聴ありがとうございました 🙏

質問があればどうぞ！

画像と音声を動画に変換

GCPのText to Speech等を使って作成した音声と、スライド画像を合成して動画にすることもできます

スライド、マルチメディア等

Claude Code作業履歴を自動で記録したい実験

⚠️ 注意: これは実験段階のメモです。実際の検証はまだ行っていません。

背景・課題

現在の問題

Claude Codeを使用してローカルで開発作業を行う際、以下の課題が発生している：

  • Claude CodeがPRを作成してくれるが、なぜその実装をしたのかの背景情報がGitHub上に残らない
  • 作業過程での判断理由や試行錯誤がローカルにしか保存されず、ほかのメンバー（後日すべてを忘れた自分自身含む）が背景を理解できない

技術的な背景

  • Claude Codeの会話履歴は ~/.claude/projects/**/*.jsonl にローカル保存される
  • GitHub上のIssueやPRには、Claude Codeの思考過程や判断理由が記録されない
  • 既存のClaude Code GitHub Actionsは、GitHub Actions上での実行を前提としており、ローカル実行の履歴は対象外

調査結果

既存事例の探索

GitHub OpsでClaude Codeの行動履歴をIssueに集めた事例を調査したが、以下のような状況だった：

アイディア

  1. headless mode: claude -p "<prompt>" --output-format stream-json でJSON形式の出力が可能
  2. GitHub CLI: gh でIssueにコメントを投稿できる

制約・限界

  • claude-code-base-actionはGitHub Actions上での実行が前提で、ローカル実行履歴は対象外
  • ローカル実行履歴をGitHub Issueに自動投稿する確立された事例は発見できず
  • この分野はまだ未開拓領域と判断される

解決策（仮説）

提案するワークフロー

以下のシンプルなアプローチで課題解決を図る：

  1. Issue作成: GitHub上で作業内容のIssueを事前に作成
  2. Claude Code実行: headless modeでClaude Codeに明示的指示
    claude -p "Issue #123を見て実装しろ。作業過程と判断理由をそのIssueにコメントとして投稿しろ" --output-format stream-json
  3. 自動記録: Claude CodeがGitHub CLIを使ってIssue commentに作業履歴を投稿
  4. PR作成: 実装完了後、PRも作成

この方法の利点

  • シンプル: 既存機能のみで実現可能、複雑な追加開発不要
  • トレーサブル: Issue上に「なぜこの実装をしたのか」が記録される

想定される技術要素

  • Claude Code headless mode (--output-format stream-json)
  • GitHub CLI (gh issue comment)
  • Issue事前作成によるコンテキスト提供

次のステップ

検証予定項目

  1. Claude CodeがGitHub CLI経由でIssue commentを投稿できるかの確認
  2. headless modeでの指示内容の最適化
  3. 作業過程記録の品質評価

期待される効果

  • PRレビュー時の文脈理解向上
  • コードメンテナンス時の背景情報活用
  • Claude Code利用時のトレーサビリティ確保
  • チーム開発における透明性向上

開発環境

WSL2でCドライブ全体をLinux側に見せないようにする方法

自分は普段Windowsを使っていて、開発もWSL上のUbuntuを使っています。簡単にLinuxを使えてとても便利です。

が、初期状態ではWindowsのCドライブ全体が/mnt/cにマウントされています。手軽に使えはするものの、WSL上で外部から取得したツールやAIエージェントを利用する場合、この設定は考え物です。何かの拍子に機密重要を含むファイルにアクセスされたり破壊されたりするわけにいきません。

そこでWSLからは必要なディレクトリしか見られないよう制限をかけました。

※ディレクトリ名は仮の名前を使用しています。

og

リスクのあるツールには必要なディレクトリだけ見せる

設定

1. Linux(WSL)で設定

Linux側で、/etc/wsl.confにautomountとinteropの項目を追加します。

~$ cat /etc/wsl.conf

[automount]
enabled = false

[interop]
appendWindowsPath = false

automountの項目だけでは下記のようなエラーが出たため、interopの項目を追加しています。

<3>WSL (346 - Relay) ERROR: UtilTranslatePathList:2878: Failed to translate C:\windows\system32

また、起動時に自動でマウントされるよう/etc/fstabに設定を追加します。

~$ cat /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM

C:/example/mydir /mnt/c/example/mydir drvfs metadata,notime,gid=1000,uid=1000,defaults 0 0

~$

2. WindowsからLinux(WSL)を再起動

Windows側に戻ってWSLを再起動。

wsl -t Ubuntu

wsl

3. Linux(WSL)上で確認

下記のように、必要なディレクトリだけが見えているようになっていれば成功です。

~$ ls /mnt/c
example

権限は絞っておくと安心

以上、Linux(WSL)からアクセスできるWindowsのファイルを制限する方法をご紹介しました。

セキュリティは使い勝手とのトレードオフになりがちです。しかし、アクセス制限が適切に設定されていることで信頼性に若干の不安があるツールも利用しやすくなる、という側面もあります。あらかじめ保険をかけていれば、「このツール、絶対便利だけどちょっとセキュリティに不安が……」と感じる場面でも積極的にリスクを取っていけるわけです。

「攻めための守備」として、アクセス権限の制限は一つの解法になりえます。

参考

ChatGPTと下記ページを参考にしました。

Memo

ブログ用画像素材生成プロンプトと便利コマンド

画像編集コマンド例

ImageMagicを利用します。

og画像(1200*630)の用意

magick input.png -gravity center -resize 1200x630^ -extent 1200x630 output.webp

png -> webp のみ

# 通常
magick input.png -quality 85 output.webp

# ロスレス
magick input.png -define webp:lossless=true output.webp

縮小のみ


magick input.webp -resize 640x output.webp

共通プロンプトパーツ

アニメ調

Anime-style illustration, the lighting is soft, highly detailed, anime style, wide aspect ratio.

イラスト調

Illustration style, soft colors, minimal background clutter, wide aspect ratio.

キャラクターのプロンプト

男性開発者

平静

Anime-style illustration of a beautiful Japanese male businessperson with flawless skin, black hair, and black eyes in a clean, high-tech office, light humor. He is wearing a finely tailored blue suit, a white shirt, and a deep navy solid-colored tie. His facial features are sharp and expressive, drawn with clean lines and high detail. The lighting is soft, highly detailed, anime style, wide aspect ratio.

He's panicking while programming on his laptop.

alt text

Making

IaCとCI/CDは何を達成すればよいのか？　導入検討にあたってすべきこと、さけるべきこと

概要と背景

かつて先進的な取り組みであったIaCやCI/CDも昨今はさほど珍しいものではなくなりました。その有益性が実感されていればこそでしょう。DORAのサイトにおいても、“Infrastructure-as-code allows you to manage changes effectively, and to apply information security controls. “と述べられるように、効果的かつセキュアな運用にIaCやCI/CDは大きく貢献します。

しかし具体的にどのようなメリットがあるのかを改めて説明しようとすると意外と難しいものです。そこでこの機にまとめなおしてみました。

og

DevOpsにつきもののCI/CD、そのメリットとは？

なぜIaCとCI/CDを用いるのか。得るべきそのメリットとは。

IaCとCI/CDのメリットをそれぞれ整理したのが以下の表です。

IaC（Infrastructure as Code）のメリット

区分具体的な利点説明
再現性同じコードから何度でも同一環境を構築可能設定漏れや設定ミスの発生を抑止し、環境差異の極めて少ない環境構築が可能になります。
可読性・共有性インフラを設定で可視化できる必然的に設定が明文化されるため、知識が属人化しにくくなります。
バージョン管理Gitでバージョン管理できるインフラをGitで管理できます。変更を追いかけるロールバックも容易です。
モジュール化による再利用共通コードで省力化何度も利用する設定をモジュール化して使いまわせば効率よく構築できます。設定ミスがおきづらいことから信頼性も高いです。
ツールの利用静的解析でチェックできるcheckovなどでコードレベルでインフラの構成をチェックできます。

実はIaC（インフラのコード化）単体ではメリットを出しづらく、多くはほかの施策や技術と組み合わせることで効果を発揮します。

例えば、再現性や可読性、モジュール化による再利用はそれを可能にするコードを書いてこそ機能します。バージョン管理はGitを導入・運用していなければなりません。静的解析のツールも同様です。

IaCの導入とは、ただTerraform（あるいはCDKやCloudFormation等）を用いるだけではなく、その他のツールや技術も合わせた総合的な施策なのだと言えます。

CI/CDのメリット

区分具体的な利点説明
自動化による信頼性向上plan -> (approve) -> apply を自動で実行できる作業ミスやメンバーごとの手順の違いなどを抑止します。運用の信頼性を向上させます。
テスト・チェックの確実な実行静的解析やterraform planなどを自動実行できるチェック忘れがなくなります。手動で行っているとフォーマッタやテストツールの実行を忘れるのも日常茶飯事です。
ガバナンス強化レビューと承認フローを必須にできるterraform planの結果とApprove機能のことです。Githubの機能と組み合わせるとさらに強力です。雑な仕事、悪意ある（！）作業を抑止できます
証跡保存コード変更・CI 実行ログが残るログがチーム共用の場に残るため追跡が容易になります。
アクセス権の保護権限をクラウド上で集中管理できる普段はCI/CDで更新するようにしておけばメンバーが普段から強すぎる権限を持たずに済みます。ただしブレイクグラスや、そこまでシビアでないならAssumeRoleなど、臨時作業の手段も用意しておく必要があります。

CI/CDの売りはなんといっても信頼性の向上です。昔から業界には作業漏れや作業ミスの笑い話（？）が絶えません。しかし自動化した部分については――自動化でミスしていれば別ですが――そのような問題を抑止することができます。逐一手順書をかかずに済むなど、本番作業の省力化に繋がることもあるでしょう。またミスのリカバリ作業が減ることからコストメリットも副次的に生じるかもしれません。

DevOps

AI連携エディタ利用を安全にする専用ユーザー作成のすすめ(Windows11)

AI連携エディタは開発作業を効率化できる便利なツールですが、機密情報をうっかり渡してしまわないよう注意する必要があります。AI連携エディタが利用したデータは外部のAIサービスへ送信されているためです。「AI連携機能を利用する」＝「外部に情報を送信する」なのです。

機密性の低い情報に対してまで必要以上に警戒すべきとは言えません。それによって効率性を損なうことは別の問題を生じます。また現実問題として外部送信程度なら許容できるケースも多くあることでしょう。しかしAPIキーや顧客の個人情報などの機密性が極めて高い情報については話が別です。このような情報は送信してしまうだけで問題、まして悪用されたとなれば大問題です。ちゃんと外部AIに学習させない設定を有効化していれば外部AIに送った情報は流用されないはずですが、完璧とは限りません。AI連携エディタのCursorの開発元自身、シビアな用途で利用する際は注意するよう呼びかけています。

While we have several large organizations already trusting Cursor, please note that we are still in the journey of growing our product and improving our security posture. If you’re working in a highly sensitive environment, you should be careful when using Cursor (or any other AI tool).
(ref: https://www.cursor.com/ja/security)

エディタ内からAIに問い合わせなければ大丈夫とも言いきれません。AI連携エディタはバックグラウンドでもAIを利用しており、気付かないうちに情報が送信されうるためです。むしろ機密情報の書かれた設定ファイルを開くだけでもリスキーと考えるべきです。つまるところ、極めて厳しいセキュリティが必要とされる情報を取り扱っているなら、それらにアクセス自体できないようAI連携エディタを物理的あるいは論理的にシャットアウトするのが一番です。

og

AIは便利だが機密情報まで送信すべきでない

専用ユーザーを作ろう

Windows11の場合、AI連携エディタを利用して開発を行うための専用ユーザーを作成することで、外部に送信される可能性のある情報をしっかり管理できます。この専用ユーザーにはあらかじめ公開可能なプロジェクトのみを渡し、機密情報が保存されたディレクトリにアクセスできないようにしておきます。うっかりミスで機密情報をAI連携エディタに渡してしまう事態を

Powershellで実施する場合はこのようなコードになります。

# AI連携エディタ用ユーザーの作成
# 
# [Usage]
# 1. 管理者権限で PowerShell を開きます。
# 2. スクリプトを一時的に実行できるようにします。(e.g. `Set-ExecutionPolicy RemoteSigned -Scope Process`)
# 3. スクリプトを保存したディレクトリに移動し、実行します。 (e.g. `.\create-ai-user.ps1 -Username AIUser -Password pass_is_here`)

param (
    [Parameter(Mandatory = $true)]
    [string]$Username,

    [Parameter(Mandatory = $true)]
    [string]$Password
)

$SecurePassword = ConvertTo-SecureString $Password -AsPlainText -Force
New-LocalUser -Name $Username -Password $SecurePassword -FullName "$Username" -Description "AI editor user (developer)"
if (-not $Username) {
    Write-Error "Fail to create user: $Username"
    exit 1
}

Add-LocalGroupMember -Group "Users" -Member $Username

管理者ユーザーではなくローカルユーザーとして作成します。その上で機密情報を取り扱うディレクトリやファイルのアクセス権を拒否し、アクセス自体不可能にします。

開発環境