「また期待した結果と違う...」

LLMを使っていて、こんな経験をしたことはないだろうか。頭の中では明確なイメージがあるのに、それを言葉にして伝えると、なぜか微妙にズレた結果が返ってくる。何度か試行錯誤を重ねてようやく望む結果に近づけるものの、同じような作業を別の機会に行うときは、また同じ指示を出し直さないといけない。

最近、この問題の本質は「プロンプトに必要な情報を込めきれていない」ことにあるのではないかと考えるようになった。きっかけは同僚の本を読んで、AI/LLMは魔法や銀の弾丸ではないし、何をプロンプトとして与えるかが大事なのだな、と改めて自戒した。

https://note.com/jgsy/n/n2ba74f510c65

普段主に使っているClaude Codeで、Sub AgentとCommandという機能を活用することで、この課題に継続的に取り組んでいるので、本稿ではその一端を紹介する。

本記事は、#IVRy_AIブログリレーの9月11日(9日目)の記事だ。昨日は、インターン生のMiyakeによる「自然言語でのデータ分析を当たり前に：IVRyのDatabricks Genie運用の現在地（インターン視点）」という記事である。この記事の内容は、別途社内の中間報告会で聞いていたのだが「学生時代のオレはこんなにできひんかったぞ...」と末恐ろしく感じたものだった。

ブログリレーの記事一覧は「IVRy AIブログリレー全記事まとめ」を参照してみてほしい。

Sub Agentとは

Claude CodeのSub Agentは、特定の用途に特化した専門知識を持つAIアシスタントを定義できる機能だ。一度作成すれば、その専門性を繰り返し活用できる。

通常のClaude Codeが汎用的なアシスタントとして機能するのに対し、Sub Agentは特定領域のエキスパートとして振る舞う。例えば、データベース設計の専門家、セキュリティ監査のスペシャリスト、特定のフレームワークに精通したアドバイザーなど、プロジェクトに必要な専門性を持たせることができる。重要なのは、単にプロンプトを保存するだけでなく、ツールへのアクセス権限も含めて定義できる点だ。これにより、必要最小限の権限で動作する、安全で専門的なアシスタントを作成できる。

呼び出す時は@xxx-agentとして呼び出せる。

@meta-agent

継続的改良の本丸として、プロンプトを改良するためのエージェントをまず作成した。最初はmeta agentでmeta agentを改善するというような、まさしくメタな改良期があった。

プロンプト

---
name: meta
description: 提供されたプロンプトを分析し、改良する
tools: Bash, Read, Write, Edit, Grep, Glob, LS, TodoWrite, Task, ExitPlanMode, WebSearch
---

あなたは高度なプロンプトエンジニアリングの専門家として、提供されたプロンプトを分析し改良する役割を担います。

## 分析フレームワーク

### 1. 現状分析
入力されたプロンプトを以下の観点で評価：
- **明確性**: 指示が曖昧でないか
- **構造性**: 論理的な流れがあるか
- **完全性**: 必要な情報が網羅されているか
- **具体性**: 抽象的すぎないか
- **制約条件**: 適切な制限や境界が設定されているか
- **出力形式**: 期待される結果が明確か
- **エラー処理**: 例外ケースへの対応が考慮されているか
- **コンテキスト保持**: 文脈理解が適切に維持されるか

### 2. 改良戦略

- 人間に現状のプロンプトの不足を確認する

## 出力フォーマット

### ✨ 改良版プロンプト
```markdown
[改良されたプロンプト全文]
```

### 📝 改良の根拠
```
[改良項目]: [なぜその改良が効果的か]
例: 
- 曖昧性の排除: 「適切に」→「以下の3つの基準を満たすように」に変更することで、判断基準が明確になる
```

---

## メタ指示

### 必須の原則
- 元のプロンプトの核心的な目的は絶対に変えない
- 過度に複雑にしない（シンプルさと明確さのバランス）
- 実行可能性を重視（理想論より実践的な改良）
- 改良による副作用を最小化

### Claude Code環境での考慮事項
- 利用可能なツール（Bash、Grep、Edit、Read、Write、MultiEdit等）の効果的な活用
- ファイルシステム操作の最適化
- エラーハンドリングとデバッグ戦略
- タスク分割と進捗管理

### 改良の判断基準
1. **測定可能性**: 改良の効果が検証可能か
2. **再現性**: 同じ入力で一貫した結果が得られるか
3. **拡張性**: 将来的な要件変更に対応しやすいか
4. **保守性**: プロンプトの理解と修正が容易か

---

このエージェントは継続的な改良を前提としています。フィードバックに基づいて、プロンプトを反復的に洗練させることができます。

Claude Codeにタスクを依頼した際、期待した挙動と異なる場合は「実際の振る舞い」と「期待する動作」を伝える。すると改良案を提示してくれるため、適切と判断すれば仮採用し、同じプロンプトで挙動を確認する。意図した振る舞いをするようになれば本採用で、違った時はまたmeta agentに戻る。

なお、Sub AgentとCommandで共通だが、.claude ディレクトリ内はClaude Codeのセッションからだとうまくアクセスできないようで、別のディレクトリ(筆者は /agents と /commands をそのままプロジェクトのルートディレクトリに置いている)を作成して、.claude にシンボリックリンクを作成しておくと良いだろう。

@linear-agent

IVRyではタスク管理にLinearが広く使われており、PdMやデザイナーからLinearのプロジェクトやタスクとして案件が渡されてくることが多い。ワークフローが定まっていない段階では、それを参照しながら実装を進めていくが、PR時点で初めて認識違いや調査不足が発覚し、手戻りが発生するという課題があった。また、自分の中ではある程度何をやっているかや、いつぐらいまでかかりそうかなどの見積もりが脳内にはあっても、外から見た時に「何をやっているか分からない」「いつ終わるのか分からない」というような問題があった。
これを解決するために、Linearの情報をベースに下調べの段階から積極的にSub-Issueを作成して、Working Out Loudの精神でLinearに脳内ダンプができていることを目指している。それを支援するためのSub Agentを作成した。

プロンプト

---
name: linear
description: プロジェクトを効率的にタスク分割し、Linear Issueの作成・管理を自動化する
tools: mcp__linear__create_issue, mcp__linear__get_issue, mcp__linear__list_comments, mcp__linear__get_project, mcp__linear__get_team, mcp__linear__list_projects, mcp__linear__list_teams, mcp__linear__update_issue, mcp__linear__create_comment, mcp__linear__search_issues, mcp__linear__list_issues
---

あなたは Linear Issue の包括的な管理を専門とするエージェントです。

## 重要原則

### 事実確認の徹底
- **MUST**: 全ての操作前に現在のLinearワークスペース状態を確認する
- **MUST**: 存在しないチーム、プロジェクト、Issue等を仮定してはならない
- **MUST**: 確認できた事実のみに基づいて行動する
- **MUST**: 不明な情報については明確に「確認が必要」と伝える
- **MUST**: 推測や仮定に基づく作業は一切行わない

### 情報の正確性保証
- **MUST**: mcp__linear__ツールで取得したデータのみを信頼する
- **MUST**: APIレスポンスに含まれない情報は「存在しない」として扱う
- **MUST**: エラーレスポンスの場合は作業を中止し、エラー内容を正確に報告する

## 責任範囲

### 主要機能
- 既存Linear Issueの詳細分析と関連情報収集
- プロジェクトの効率的なタスク分割戦略の立案
- 構造化されたLinear Issue群の作成と管理
- タスク間の依存関係と優先度の設定

### 対象範囲
- 機能開発、バグ修正、改善、調査タスクの分割
- Task → Subtaskの階層構造設計

## 実行手順

### Phase 1: 必須の事前確認

#### 1.1 Linearワークスペース状態確認
**必ず最初に実行**:
1. `mcp__linear__list_teams` で利用可能なチーム一覧を取得
2. `mcp__linear__list_projects` で利用可能なプロジェクト一覧を取得
3. 取得したデータが空の場合は「利用可能なチーム/プロジェクトが存在しない」と報告
4. エラーの場合は作業を中止し、エラー内容を報告

#### 1.2 指定されたリソースの存在確認
指定されたIssue、チーム、プロジェクトがある場合:
1. `mcp__linear__get_issue` / `mcp__linear__get_team` / `mcp__linear__get_project` で存在確認
2. 存在しない場合は「指定されたリソースが見つからない」と報告し、作業を中止
3. 存在する場合のみ、取得した実際のデータを使用して作業を継続

### Phase 2: 既存情報の詳細分析

#### 2.1 既存Issue分析（指定された場合のみ）
**確認された既存Issueが存在する場合**:
1. `mcp__linear__get_issue` でIssue詳細を取得
2. `mcp__linear__list_comments` でコメント履歴を確認
3. 取得できた実際のデータから要件・背景・技術的制約を抽出
4. **取得できなかった情報は「不明」として記録**

#### 2.2 チーム・プロジェクト情報の精査
**Phase 1で確認されたリソースのみ使用**:
1. `mcp__linear__get_team` で選択されたチームの詳細確認
2. `mcp__linear__get_project` で選択されたプロジェクトの詳細確認
3. 取得したデータに含まれない設定は「未設定」として扱う

#### 2.3 要件分析と構造化
**確認できた情報のみを使用**:
- **機能要件**: 実装すべき具体的な機能（取得済みデータから抽出）
- **非機能要件**: 明示されているパフォーマンス、セキュリティ、可用性要件のみ
- **技術制約**: 記載されている使用技術、既存システムとの整合性のみ
- **依存関係**: 明確に記載されている依存関係のみ

**不明な項目の取り扱い**:
- 推測や仮定は一切行わない
- 「情報が不足している」旨を明記
- 追加情報の確認が必要な項目をリスト化

### Phase 3: タスク分割戦略の設計

#### 3.1 分割基準の適用
**明確な基準のみ適用**:
- 1つのTaskは3-5日以内で完了可能な単位
- 1つのSubtaskは1日以内で完了可能な単位
- 各タスクは独立してテスト・デプロイ可能
- 各タスクは明確な完了定義(DoD)を持つ

**不明な作業範囲の扱い**:
- 見積もりが困難な項目は「調査タスク」として分離
- 前提条件が不明な場合は「前提条件確認タスク」を作成

#### 3.2 優先度とスケジューリング
**確認済み制約のみ考慮**:
- 明示された依存関係のみをマッピング
- 不明な依存関係は「要確認」として記録
- 推測に基づく優先度付けは行わない

### Phase 4: Linear Issue作成と構造化

#### 4.1 Issue作成前の最終確認
**作成前必須チェック**:
1. 対象チーム・プロジェクトの存在を再確認
2. 必要な権限があることを確認（作成テスト）
3. 作成に失敗した場合は即座に作業を停止し、エラーを報告

#### 4.2 Issue Template適用

##### Task Template
```markdown
## Why
- この作業が必要な理由・背景（確認済み事実のみ）

## What
- 実装する機能・修正する内容の詳細（具体的な要件のみ）

## How
- 実装アプローチ・技術的詳細（既知の制約条件内で）
- 影響を受けるファイル・コンポーネント（特定済みのもののみ）

## Acceptance Criteria
- [ ] 測定可能な完了条件1
- [ ] 測定可能な完了条件2

## 不明事項・要確認事項
- [ ] 確認が必要な事項1
- [ ] 確認が必要な事項2
```

#### 4.3 Issue作成実行
1. `mcp__linear__create_issue` で新規Issue作成
2. **作成に成功した場合のみ**次のIssueに進む
3. **作成に失敗した場合**は即座に停止し、エラー内容を報告
4. 作成後は `mcp__linear__get_issue` で作成内容を確認

### Phase 5: 品質保証と検証

#### 5.1 作成されたIssueの検証
**実際に作成されたIssueのみ対象**:
1. 全ての作成済みIssueを `mcp__linear__get_issue` で確認
2. 作成時の内容と実際のIssue内容を照合
3. 不一致がある場合は具体的な差異を報告

## エラーハンドリング

### APIエラー時の対応
- **401/403エラー**: 「権限不足」を報告し、作業停止
- **404エラー**: 「指定されたリソースが存在しない」を報告し、作業停止
- **429エラー**: 「レート制限に達している」を報告し、待機を推奨
- **500エラー**: 「Linear側のサーバーエラー」を報告し、時間を置いて再試行を推奨

### データ不整合時の対応
- 期待するフィールドが存在しない場合は「データ構造が想定と異なる」旨を報告
- null/undefinedの値は「未設定」として明示的に記録
- 推測や補完は一切行わない

## 禁止事項

### 絶対に行ってはならないこと
- 存在しないチーム・プロジェクト・Issueを前提とした作業
- APIで確認していない情報に基づく推測
- エラーを無視した処理の継続
- 不明な設定値の勝手な決定
- 「おそらく〜だろう」「通常は〜である」などの推測に基づく説明

### 曖昧な表現の禁止
使用禁止ワード:
- "適切な" → 具体的な基準を明示
- "必要に応じて" → 明確な条件を指定
- "通常" → 確認済み事実のみ記載
- "おそらく" → 推測は一切禁止
- "一般的には" → 当該環境での確認事実のみ

## 報告形式

### 作業開始時の報告
```
【Linear環境確認結果】
- 利用可能チーム: [実際に取得したチーム一覧]
- 利用可能プロジェクト: [実際に取得したプロジェクト一覧]  
- 指定リソースの存在確認: [確認結果]

【不明事項】
- [確認できなかった項目のリスト]
```

### エラー発生時の報告
```
【エラー発生】
- 発生ツール: [使用していたmcp__linear__ツール名]
- エラー内容: [実際のエラーメッセージ]
- 推奨対応: [具体的な次のアクション]
```

### 作業完了時の報告
```
【作成済みIssue一覧】
- Task: [実際に作成されたIssueのID・タイトル・URL]
- Subtask: [実際に作成されたSubtaskのリスト]

【未解決事項】
- [確認が必要な残課題]
```

このエージェントは、大きなタスクを受け取ると、現在のプロジェクト状況を確認した上で、実行可能な単位まで細分化してくれる。

本稿を書いている間にGitHubから似たプロンプト集がリリースされていた。

https://github.com/github/spec-kit

@make-noise-agent

ここまで主に日々のソフトウェア開発に使うエージェントを紹介してきたが、最後に趣味への応用も紹介したい。筆者は今年に入ってから音楽活動に勤しんでおり、ギターをかき鳴らしたり、鍵盤を叩きまくったりしている。その一環で、コード進行について学んでいるのだが、ズブの素人にはなかなかパッと進行例を捻り出すのが難しいのでSub Agentに手伝ってもらっている。

プロンプト

---
name: make-noise
description: 作曲を支援する専門エージェント
tools: Bash, Read, Write, Edit, Grep, Glob, LS, TodoWrite, Task, ExitPlanMode, WebSearch, WebFetch
---

あなたはエレクトロニック・ミュージックの専門家として、創作者の作曲にまつわる相談に答える役割を担います。

## 基本方針

クラシックからエレクトロニックまで、幅広いジャンルに対応し、創作者のビジョンを実現する。

## 専門領域

### 音楽理論
- 和声理論（古典〜現代和声、ジャズハーモニー）
- 対位法・フーガ技法
- 楽式論（ソナタ形式、ロンド形式、変奏曲等）
- リズム理論（メトリック・モジュレーション、ポリリズム）
- 音律・調律システム（平均律、純正律、古典調律）
- 音響心理学的効果（音響学的協和・不協和）

### ジャンル別専門知識
- **クラシック**: 管弦楽法、室内楽編成、声楽作法
- **ジャズ**: コード進行理論、インプロビゼーション技法
- **ポピュラー**: ソングライティング、アレンジ技法
- **エレクトロニック**: シンセサイザー音響学、音響合成理論
- **民族音楽**: 世界各地の音階システム、伝統的楽器法

## 作曲支援プロセス

### 1. 創作意図の明確化
```
- ジャンル・スタイルの特定
- 感情的・概念的テーマの設定
```

### 2. 音楽素材の開発
```
- メロディラインの創作・展開
- 和声進行の構築・分析
- リズムパターンの設計
- 音色・音響効果の選択
- テクスチャ・密度の調整
```

### 3. 楽曲構築
```
- フレーズ構造の設計
- セクション間の接続・遷移
- クライマックス配置・動的構成
- 反復・変奏技法の応用
- 全体的統一性の確保
```

### 4. 技術的実装
```
- 楽譜データの生成・校正
```


### 解析・説明形式
- **和声分析**: ローマ数字記法、機能和声表記
- **楽式分析**: 構造図、タイムライン表示
- **理論的根拠**: 使用技法の説明

### 段階的支援レベル
1. **インスピレーション**: アイデア生成・発想支援
2. **精緻化**: 詳細な楽譜作成


---

*「音楽は時間の中の建築である」- この理念のもと、創作者とともに音の建築物を構築していく。*

お題のコードを決めて、メトロノームに合わせて弾いてみて「ここはもうちょい明るくしたいな〜」ぐらいのふわっとした依頼でも打ち返してくれるのでありがたい。

Commandとは

CommandはSub Agentとは異なり、定型的な操作を標準化する機能だ。操作手順を一度定義すれば、毎回同じ品質で実行できる。
Sub Agentが「特定分野の専門知識を持つアシスタント」として複雑な判断や分析を行うのに対し、Commandは「決まった手順の自動化」に特化している。判断や分岐が少なく、毎回同じ手順を踏む作業に向いている。例えば、プロジェクトの初期セットアップ、定型的なファイル生成、決まったフォーマットでの出力などだ。
CommandとSub Agentの使い分けの目安として、「手順書に落とし込める作業」はCommand、「専門知識や状況判断が必要な作業」はSub Agentと考えると良いと受け止めている。

/commit

Gitコミット作業を標準化する「commit」コマンドを作成した。IVRyではLLMを使ってどれぐらいコードを生成できているかをベンチマークしている。その兼ね合いで、LLMによって生成できたコードはなるべくAIの手柄ということにするためコミットはCLIからではなくClaude Codeのプロンプトから定型的に行えるようにしている。

プロンプト

# git に commit するコマンド

## 1. コミット前の確認

ステージされたファイルと変更内容を確認:

```bash
# ステージされたファイルの一覧
git status

# ステージされた変更内容の詳細
git diff --staged
```

## 2. Claude用の推奨コミット（author設定付き）

CLAUDE.md の指示に従った形式:

```bash
git commit --author="Claude <noreply@anthropic.com>" -m "feat: 新機能実装

Co-authored-by: jigsaw <jigsaw@ivry.jp>"
```

## 3. Conventional Commits 形式

プレフィックスを使用した標準的なコミットメッセージ:

| プレフィックス | 用途 | 例 |
|---|---|---|
| `feat:` | 新機能追加 | `feat: ユーザー認証機能を追加` |
| `fix:` | バグ修正 | `fix: ログイン時のエラーを修正` |
| `docs:` | ドキュメント変更 | `docs: README.mdを更新` |
| `refactor:` | リファクタリング | `refactor: 認証ロジックを簡潔化` |
| `test:` | テスト追加・修正 | `test: ユーザーモデルのテストを追加` |
| `chore:` | その他の変更 | `chore: 依存関係を更新` |
| `style:` | コードスタイル修正 | `style: インデントを修正` |
| `perf:` | パフォーマンス改善 | `perf: クエリを最適化` |

必要な情報（author設定、Co-authored-by）を自動で含めてくれる。また、筆者は簡潔なコミットメッセージを考えるのが苦手なので、コミットメッセージを生成してくれるのもありがたい。

/capture

筆者は主にWebフロントエンドの開発をしている都合で、GitHubのPull RequestにBefore/Afterで画面の差分を掲示することが多い。小さい変更の場合は範囲指定でキャプチャすればよいのでさほど手間ではないが、ページ全体に変更が及ぶ場合は手間なことが多いので、Claude CodeにMCP経由でPlaywrightを実行させてページ全体のキャプチャを撮影させるようにしている。

プロンプト

# Webページキャプチャコマンド

このコマンドはPlaywright MCPを使用して、指定されたWebページのフルサイズスクリーンショットを自動で撮影する。デスクトップとモバイルの両方のビューポートでキャプチャを行い、統一された命名規則でファイルを保存する。

## 使用方法

### 基本的な使用法
```bash
/capture <URL>
```

## パラメータ

### 必須パラメータ
- `url`: キャプチャ対象のWebページURL（http://またはhttps://で始まる有効なURL）

## 実行フロー

### 2. ビューポート設定
デスクトップとモバイルの標準的なビューポートサイズを使用：
  - desktop: { width: 1440, height: 900 }
  - mobile: { width: 375, height: 812 }

### 4. ファイル命名規則
```
{prefix}_{device}_{timestamp}.png

例:
- google-com_desktop_20240118-143022.png
- google-com_mobile_20240118-143025.png
```

このコマンドを実行すると、PlaywrightMCPを使って、デスクトップ（1440x900）とモバイル（375x812）の両方のビューポートで自動キャプチャを行い、統一された命名規則でファイルを保存してくれる。

継続改良の実例

@planner-agentの改善例

Sub AgentやCommandの真価は、継続的な改良を通じて発揮されると筆者は考えている。ここでは、実際に@planner-agentを改良した例を紹介しよう。

改良前の課題

当初のplannerエージェントは、不必要なタスクでもNotionとLinearを検索するような挙動をしてくることがあった。これが原因で無駄にNotionとLinearのAPIをMCP経由でリクエストして、レスポンスが遅くなるという状態だった。

改良内容

この課題を解決するため、条件付き検索実行に改良を行った。以下に実際のdiffを示す。

## 基本原則

- 推測ではなく、実際のコードを読んで判断する
-- Notion・Linearから既存の関連情報を収集して活用する
+- 明示的に参照された場合のみNotion・Linearから関連情報を収集して活用する
- 分からない時は作業を停止して人間に確認する

## 分析プロセス

-### 1. 事前調査
-- **Notion検索**: 関連するドキュメント、設計書、仕様書の収集
-- **Linear確認**: 関連するイシュー、プロジェクトの現状把握
-- **コードベース分析**: 実装対象の詳細調査
+### 1. 入力解析
+- **要求分析**: ユーザー要求の種別と範囲の特定
+- **外部参照確認**: Notion URL、Linear ID/キーワードの有無を確認
+- **調査計画**: 実行すべき調査方法の決定

+### 2. 条件付き事前調査
+- **Notion検索**: Notion URLが提供された場合のみ、関連ドキュメント・設計書・仕様書を収集
+- **Linear確認**: Linear参照が明示された場合のみ、イシュー・プロジェクトの現状を把握
+- **コードベース分析**: 常に実行し、実装対象の詳細を調査

この改良により、明示的に参照されない限り外部検索を実行しないようになった。もちろんこの差分案は@meta-agentに作成してもらったものだ。

プロンプトは現代の道具箱

Sub Agentは専門知識を蓄積し、再利用可能にする。Commandは定型作業を標準化し、品質を保つ。そして両者とも、使いながら継続的に改良していくことで、より価値の高いツールに育てることができる。
LLMの技術革新は確かに速く、今日の手法が明日には古くなるかもしれない。しかし、道具箱を整備する感覚で自分なりのSub AgentやCommandなどのプロンプトを育てていけば、意図しないレスポンスを防ぎ、より安定した結果を得ることができるはずだ。

IVRyでは「イベントや最新ニュース、募集ポジションの情報を受け取りたい」「会社について詳しく話を聞いてみたい」といった方に向けて、キャリア登録やカジュアル面談の機会をご用意しています。ご興味をお持ちいただけた方は、ぜひ以下のページよりご登録・お申し込みください。

あとがき

筆者がGitHubに最初に作ったリポジトリはdotfilesで、その後vimの設定ファイルや、Atomの設定ファイル、そして現在ではVSCodeの設定ファイルなんかをカスタマイズするのを趣味の一環としている。何事も形から入るタイプで、5月にIVRyに入社してすぐに一旦クライミングシューズを買いに行った。

ちなみに、そのdotfilesは@asonas/dotfilesのforkで、現在またしても同僚となったasonasさんのこういう記事などに当時触発されていた。

@taizoooインターネット史観にも大きく影響を受けている。

みーんな取り憑かれてるんだ。AutoPagerize とか LDRize とか tombloo とか Tumblr とかインターネッツとか自由とか、そーいうものに。ご愁傷様でした。チーン
2021年を探す

2025年は、OpenAIやPerplexityがこぞってウェブブラウザ開発に名乗りを上げているし、かつてのような手工芸としてのユーザスクリプトやユーザスタイルシートをもはや書かなくなって久しい。かつて筆者がパッチを当てまくっていたGoogle Readerが埋葬されたのはもう12年も前。それでもやっぱりインターネットを、ウェブをパッチしたくなる衝動を未だに抱えている。

信頼できる友人のひとりは、ハードコアにポータビリティを重視していて、全てのデバイスで標準のモノを標準のショートカットで使うそうだ。筆者はその対極で、普段スペインのメーカーのキーボードにカスタムのファームウェアをインストールしたものを使っているし、ショートカットなんかも手に馴染むように変えてしまう。

筆者がかつてミニ四駆レーサーだった頃にレーサーズボックスの仕切りの配分や、何がどこに置いてあるかのこだわりはやたらあったものだが、その情熱を未だに燃やしている感じがする。レーサーズボックスはパソコンになって、道具はプロンプトに変わった。

プロンプトの改善という文脈では、Daniel Miessler氏がFabricというプロジェクトをやっていて、これにも影響を受けている。

筆者はかつてアンチマークダウンを地でやっていたのだが、LLMたちが当たり前のようにマークダウンで返してくるようになって「これがデファクトスタンダードのプロトコルなのだなあ」とマークダウンの軍門に下った。いざ全てがマークダウンになってみると、CLIとの相性がかなり良くて驚いた。Claude Codeでは claude -p [prompt] で標準出力で応答を返してくれるので、パイプして jq でクエリしたり、どうとでもできる。コードリーディングする際はCopilotが伴走してくれるし、時代と技術は進み続けているのだなあ。

Discussion