個人レベルで色々と試していることがあるので、勉強会の機会に共有します。
Anthropic. スラッシュコマンド. Claude Docs.
https://docs.claude.com/ja/docs/claude-code/slash-commands
インタラクティブセッション中にスラッシュコマンドでClaudeの動作を制御します。
Anthropic. スラッシュコマンド. Claude Docs.
https://docs.claude.com/ja/docs/claude-code/slash-commands
チャットUIは質問するときは便利ですが、指示することにはあまり向いていないと思っています。
音声入力の活用も可能ですが、そもそも指示とは自然言語で一から構築するものではないように思います。
もしかしたら、IDEと連携してボタンUIなどで呼び出せると便利なのかもしれません。
背景
In-Context Learning（Few-shot プロンプティングに相当するとされる手法）は、数理的には低ランクファインチューニングに近い？とする主張があるようです。
もしその主張が正しいとすれば、本稿のような工夫にも一定の意義があると言えそうです。
Benoit Dherin, Michael Munn, Hanna Mazzawi, Michael Wunder, Javier Gonzalvo. Learning without training: The implicit dynamics of in-context learning. arXiv, 2025年7月21日.
https://arxiv.org/abs/2507.16003v1
注意
インタラクティブセッションに過度に依存せず、まずは設計文書や「初期プロンプト」をエージェントと協働しながら適切に整備することが前提となります。
（勉強会参加者の声：「オフショア開発」くらいの粒度の設計・指示が良いのではないか）
「まず生成させ、結果から少しずつ学ぶ」という方針も試してはみたのですが、あまり本質的でない知見ばかりが得られる印象があって、やめました。
また、適切なツールを選定するということについても同様に重要です。下記のようなベンチマークもあるので、参考にしましょう。
laiso. TypeScriptファーストなコーディングAIエージェントのベンチマーク「ts-bench」を公開しました. laiso Blog, 2025年9月5日.
https://blog.lai.so/ts-bench/
カスタムスラッシュコマンドの例
最近個人的に使ったものを共有します。見ればわかる通り、荒削りなものばかりです。
まずは共有などは意識せずに ~/.claude/commands/ へどんどん書いていけばいいと思っています。
たとえ一行の指示であっても、書き出すことで多少なりとも検証可能性を得られるかなと思います。
feature.md
当初はKiroとの連携を目的に作成しましたが、結局はいつでも使っています。
課題に必要なコンテキストを文書として管理して、セッションをいつでも終了できるようにします。
追加プロンプトで「引数」を渡す想定です。
{課題番号}について、gitのブランチで作業が進行しています。まず下記を読み込んでください。
Git: ({commit sha} || develop)..HEAD
Docs directory: .kiro/specs/{課題番号}/
Requirements: requirements.md
Design: design.md
Tasks: tasks.md
Other documents: *.md
- tasks.mdにチェックを入れながら進めます
- 絵文字は禁止です
- この課題に関連するspecにはfdescribeでfocusします。specのfocusは外さないでください
- specを書くときは、最初に既存specの類似パターンを徹底調査してください
ついでに課題進行のルールなどもここに書いています。本筋ではないですが、この例では自動テストを人間が実行しながら、エージェントとペアプロするように仕上げていく工程のためのルールを書いています。
（勉強会参加者の声：デバッグログを出力するようなルールを指示することはおすすめ）
（勉強会参加者の声：Sonnet 4.5は不足している情報を適切に質問できるようになったように思う）
以下のように使います。
/feature PROJECT-1下記でルールを思い出してもらったりしています。しかし、ルールを忘れるころには、そもそもコンテキストが荒れているのかもしれません。
/feature 思いだしてspec-rules.md
Claude Codeは自動テストに失敗すると、自律的に修正を試みてくれますが、それがあまりうまくいってないとき用の指示です。
- 【最優先】最初に既存specの類似パターンを徹底調査してください
- 想像で判断したり変更するのではなく、NG出力から確実に言えることを根拠にしてください
- 確実に言えることがないなら、コードにputsなど加えて実行してください
- putsでの診断も有効ですが、可能なら失敗期待テストを優先してください（診断と恒久テストを兼ねられ、後で削除不要のため）
- 例: `expect(method).to eq true` → 失敗時のNG出力で問題特定、修正後は継続的なテストとして機能そもそもなぜうまくいっていないのか？の理由（↓）にアプローチするべきなのかもしれませんが、なかなか難しい状況もあると思います。
- 現状のテスト設計では、NG出力から十分な情報を得ることができない
- 前提として、自動テストの出力がエージェントに向いていない
- コンテキストが整理されていない
design-improve.md
エージェントはコードの「元の状態」にアテンションを払うのが苦手な印象があるので、下記のような指示を試しているところです。
design.mdについて下記の観点で改善できないか、検討をお願いします
- 「既存コード」セクションを追加して、関連する既存コードを引用するしかし、既存コードをコンテキストにまるごと含めるより、専用のサブエージェントを定義してコードを取ってきてもらう方が適切かもしれません。
reload.md
人間や他のエージェントによってファイルが更新されたことを伝えるために書きました。意外と意図が伝わらないことが多く、まだ工夫の余地がありそうです。
こちらでファイルを変更しました。わかりますか？memo.md
開発に必要な知識がCLAUDE.mdにもコードベースにも表現されていないと思ったときは、とりあえず課題単位のメモとして書き出しています。
後で内容を選別してCLAUDE.md にマージしたり、コードコメントに書いたりします。
このセッションで、私に指摘されるまでわからなかった知識を、あなた向けにまとめて、この課題のドキュメントディレクトリのmemo.mdに記載してください。推奨手順などは他のコンテキストで有害になりますので、あくまで知識という観点で記載をお願いしますtrim-space.md
フォーマッタを使いなさい、という話でしかないのですが、間に合わせでこのようなツールもどきを使ったりします。
これがコンテキストに載ることで良いことがあるかなとも思ったのですが、逆かもしれません。
作成したファイルに、スペースだけの行を含んでしまっています。スペースを削除してください発展: 作成したコマンドを知識に
定義したコマンドを後で振りかえって、サブエージェントやエージェント向けツールの設計に生かせるのではないかと思います。指示が必要であったということは、そこに何らかの「境界」が存在することを示唆するからです。
LLMの発展で乗り越えられる？
その「境界」は、今後のLLMの発展で自動的に乗り越えられるのでしょうか？
世界の消費電力などの観点から見て、現状のようなLLMの発展・利用が必ずしも持続可能であるとは限りません。例えばコーディングエージェントについて言えば、小型で高速なLMの組み合わせが主流になるなど、さまざまな発展の可能性がまだ残っていると思います。
非トランジスタ光学回路（SLM）を用いて、拡散モデルによる学習・画像生成を実施した論文があります。将来的には拡散言語モデルと組み合わせ、実用化されるのかもしれません。
Chen, S. et al. Optical generative models. Nature 615, 102–109 (2025).
https://www.nature.com/articles/s41586-025-09446-5
Shi3z. ついに来た拡散言語モデル. Note, 2025年3月2日.
https://note.com/shi3zblog/n/n608e125e95ac
MCPサプライチェーンリスク
MCPの導入について上記しましたが、リスクアセスメントが必要です。
大元隆志. MCPサプライチェーンリスク：実在するMCP-Serverへのなりすまし攻撃が顕在化. Yahoo!ニュース（エキスパート）, 2025年9月30日.
https://news.yahoo.co.jp/expert/articles/d7c29229854c334c2f26f77c15ffd13740dd1039
Jxck. サプライチェーン攻撃への防御策. Jxck’s Blog, 2025年9月20日.
https://blog.jxck.io/entries/2025-09-20/mitigate-risk-of-oss-dependencies.html
