白猫のメモ帳

C#とかJavaとかJavaScriptとかHTMLとか機械学習とか。

Kiroが使えるようになったので試してみよう

こんばんは。
お盆にまとめてお休みをする習慣がないのですが、なんとなくちょっと特別感はありますね。

さて、Wailtlistに登録してから何の音沙汰もなかったKiroから使えるようになったよというメールが来たので使ってみます。
今回作ったものはこちらです。

github.com

進め方

Claude CodeやCursorなどのコーディングエージェントにリクエストをすると、勝手にプランを立ててどんどん作業を進めてくれます。
いわゆるVibeコーディングという形で勝手に進めてくれるのは気軽でよいのですが、最後まで出来上がってからちょっと違うなとなると結構リカバリが大変です。

もちろんプロンプトで指定をして先に設計をさせるとか、タスクリストを作らせるといったこともできるのですが、Kiroは「こういうことがしたいよ」というリクエストをすると、最初からRequirements→Design→Task listという順で作業を進めてくれます。

今回はこんなプロンプトから始めてみましょう。

現状のAIやエージェントにおいてはRAGを中心としたプロンプトへの知識の差し込みを中心としているため、 知識の偏りはあっても思考の偏りはあまりなく、極めて平均的な振る舞いをします。
そのため、意図的に思考の偏りやバイアスをかけないと、意味のあるアブダクションは生まれないと思います。
より発展的な思考を促すために、取り組む課題によって異なるペルソナを差し込むMCPを作りましょう。

Requirements(要件定義)

できたものがこちらです。最初は日本語と英語が変に混ざってしまっていたので、初期プロンプトに日本語でやりとりしたりファイルを作ってねと入れておくとよさそうです。

# 要件定義書

## 概要

この機能は、AIエージェントやLLMの思考パターンに意図的なバイアスや専門性を注入することで、より創造的で発展的な思考を促すMCP(Model Context Protocol)サーバーを開発します。現在のRAGベースのアプローチでは知識の差し込みは行えても思考の偏りは生まれにくく、結果として平均的で予測可能な回答しか得られません。このシステムは、取り組む課題の性質に応じて適切なペルソナを選択・適用し、より意味のあるアブダクション(仮説形成)を可能にします。

## 要件

### 要件1

**ユーザーストーリー:** 開発者や研究者として、取り組んでいる問題の種類に基づいてAI会話に異なるペルソナを動的に注入したい。そうすることで、汎用的な回答ではなく、より創造的で専門的な思考パターンを得ることができる。

#### 受け入れ基準

1. WHEN ユーザーが問題領域やタスクタイプを指定した場合 THEN システムはそのコンテキストに適したペルソナを自動的に提案する
2. WHEN ユーザーがペルソナを選択した場合 THEN システムはそのペルソナに関連する特定の思考パターン、バイアス、アプローチを会話コンテキストに注入する
3. WHEN ある領域に複数のペルソナが利用可能な場合 THEN システムはユーザーがそれらから選択するか、複数の視点を組み合わせることを可能にする

### 要件2

(略)

長いので省略しましたが、要件6まで作ってくれています。
フルサイズはこちら

WHEN~THEN~っていう書き方が特徴的ですね。
お試しなので、特に修正の依頼はせずにDesignに進みます。
この辺りの順番に進める形がちゃんとUIとして組み込まれているのが親切でいいですね。

Design(設計)

はい。こんな感じで、いわゆる設計書を作ってくれます。
個人的にはCursorとかでもちょっと大きいことをしようとすると大抵こんな感じのものは作ってもらっていますね。

# 設計書

## 概要

ペルソナ注入MCPサーバーは、AIエージェントの思考パターンに専門的なバイアスや視点を動的に注入するためのModel Context Protocolサーバーです。このシステムは、問題領域に応じて適切なペルソナを選択し、そのペルソナの認知的特性をプロンプトコンテキストに組み込むことで、より創造的で専門的な回答を促進します。

## アーキテクチャ

### システム構成

```
┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   AI Client     │◄──►│  MCP Server      │◄──►│  Persona Store  │
│   (Kiro/Claude) │    │  (TypeScript)    │    │  (JSON Files)   │
└─────────────────┘    └──────────────────┘    └─────────────────┘
                              │
                              ▼
                       ┌──────────────────┐
                       │  Context Engine  │
                       │  (Prompt Builder)│
                       └──────────────────┘
```

### 主要コンポーネント

1. **MCP Server Core**: JSON-RPC 2.0プロトコルでクライアントと通信
2. **Persona Manager**: ペルソナの管理、選択、適用を担当
3. **Context Engine**: ペルソナの特性をプロンプトコンテキストに変換
4. **Persona Store**: ペルソナ定義の永続化ストレージ
5. **Tool Registry**: MCPツールの定義と実行

(略)

フルサイズはこちら

感想としては過不足なく良くまとまった設計かなと思います。
自分で指示すると、なんか楽しくなっちゃったのかいくつもmarkdown作って延々設計してることがあるのでいい感じに調整できてるんじゃないでしょうか。

Task list(実装計画)

はい。これも大きめのタスクを頼むときにはよく使う方法ですね。

# 実装計画

- [ ] 1. プロジェクト構造とコア型定義の設定
  - TypeScriptプロジェクトの初期化とMCP SDKの依存関係設定
  - ペルソナとコンテキストの型定義を作成
  - _要件: 4.1, 4.2_

- [ ] 2. ペルソナストレージシステムの実装
  - [ ] 2.1 PersonaStoreインターフェースとファイルベース実装の作成
    - PersonaStoreインターフェースを定義
    - FileSystemPersonaStoreクラスでJSONファイルの読み書き機能を実装
    - _要件: 2.2, 3.2_

  - [ ] 2.2 デフォルトペルソナセットの作成
    - 10種類のデフォルトペルソナ(科学者、起業家、芸術家など)のJSON定義を作成
    - 各ペルソナの思考パターン、バイアス、専門領域を詳細に定義
    - _要件: 2.1, 2.2_

- [ ] 3. ペルソナ管理システムの実装
  - [ ] 3.1 PersonaManagerクラスの作成
    - ペルソナの検索、取得、保存機能を実装
    - ドメインベースのフィルタリング機能を実装
    - _要件: 1.1, 2.3, 3.1_

(略)

フルサイズはこちら

結構しっかりとタスクを定義してくれるので、ここでチェックをちゃんとできれば手戻りはかなり減りそうな予感です。
ちなみに、エディタ上に「Start task」という形で表示されて順番に実行できるので、コントロールは効きやすそうですね。


タスクの実行

あとは順番にタスクを実行していく形です。
タスクの実行中はこんな感じでくるくるします。何してるかわかりやすい。

ちなみにこの間にもチャット欄は進んでいきます。
このタイミングで急に日本語でやり取りしてねっていうのを無視しだすあたりがまだPreview版なのかもしれません…。
「Start task」ではなく、「続きのタスクを進めてください。やり取りは日本語で。」とか書いたら普通に進めてくれました。

結構実装の時間はかかる印象ですね。
細かくテストを書いては、全部パスさせて先に進むやり方で手堅いです。


どれくらい使えるの

ちょうど料金プランが適用されるようになったので使い放題というわけではないです。
現状で登録すると、SpecとVibeにそれぞれ100のボーナスクレジットがもらえます。

それぞれSpecを作るのとVibe Codingをするのに使われるのかと思ったのですが、Specを準備しているときにはVibeを利用して、実装しているときには主にSpecを利用しているみたいでした。(微妙にVibeも減ってた)
逆じゃないのか…ややこしいぞ。

料金プランはこんな感じなので、結構すぐなくなってしまいそうですね。
私も今回のプロジェクト作ったらSpecを100使い切ってしまいました。悲しい。


まとめ

というわけで、Requirements→Design→Task listのSpec作成の部分は個人的には結構好みでした。
面倒だから1プロンプトで最初から最後まで全部やってくれよという人には向かないかもしれませんが、先にドキュメントで確認できるのはいいですよね。

コーディング能力自体も性能は結構よさそうかなとは思うのですが、ここは単純にクレジットがすぐに足りなくなりそうなのが気がかりです。
コスパを考えると、現時点だとSpecまで作ってもらって、続きはClaude Codeに任せたいですかね。

ともあれ選択肢が増えるのは良いことです。
今後の動向にも期待したいです。