👩‍💻

Kiro で Serena を使う手順

に公開
AI
C#
AIエージェント
Kiro
Serena
tech

Amazon Kiro で Serena をセットアップする手順です。

  • Kiro 以外の VS Code 互換エディターでも通用する内容だと思います。
  • ２行だけ C# プロジェクト専用のセットアップが含まれています。
  • 文中のコマンドは PowerShell で実行します（Windows）

なお、Kiro に導入しても「賢くなる」という効果は無いと思います。

事前準備【UV のインストール】

UV は Rust で書かれた Python 向けの npm npx と認識しておけばおｋです。

Windows

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Linux

curl -LsSf https://astral.sh/uv/install.sh | sh

公式マニュアル 👉 https://docs.astral.sh/uv/getting-started/installation/

Serena のセットアップ

（省略可）公式の設定ファイルを ~/.serena（%USERPROFILE%\.serena）フォルダーにコピーします。

デフォルトのままだと MCP が起動するたびに「勝手にブラウザが開く」ので、

  • web_dashboard_open_on_launch: false

で、必要に応じてオフに設定します。

👇 公式テンプレート

https://github.com/oraios/serena/blob/main/src/serena/resources/serena_config.template.yml

Kiro のセットアップ

MCP サーバーとエージェントの Steering を設定します。

Kiro Panel

MCP Servers の設定

以下を貼り付けます。必要に応じて git の特定のバージョンをピン止めします。

{
  "mcpServers": {

    //...既存の設定...

    "serena": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/oraios/serena",
        "serena-mcp-server",
        "--context",
        "ide-assistant"
      ],
      "env": {}
    }
  }
}

uvx でバージョンをピン止めする方法は git+<REPOSITORY_URL>@ref です。ref にはタグやコミットハッシュ等が使えます。

例： v1.0.3 にピン止め（最新ですがちょっと古いのでハッシュでのピン止め推奨）

"git+https://github.com/oraios/serena@v1.0.3",

Serena の起動確認

Agent Steering の設定

コード生成に関わる処理で serena が使われるようにセットアップします。

fileMatchPattern で指定しているファイル拡張子は開発環境に合わせて適宜調整します。

Kiro（Claude Sonnet）と C# の相性が良くないので追加の設定をしています。最後の２行は無くても良いです。

csharp-editing.md
--
inclusion: fileMatch
fileMatchPattern: "**/*.cs"
--

- SHALL use mcp server `serena` to retrieve and edit source code.
- SHALL organize test related files in `tests` folder.
- SHALL NOT use `csc` to compile source code.

プロジェクト単位のセットアップ

以下のコマンドは全て対象のプロジェクトフォルダーで実行します。

/mcp__serena__initial_instructions

README に実行せよと書いてありますが、今時点の環境では不要です。古い Claude Code 向けです。

プロジェクトのアクティベート

uvx --from git+https://github.com/oraios/serena serena-mcp-server --project "$(pwd)"

実行すると MCP サーバーが起動します。起動するだけで良いので Ctrl + C で即終了します。

（~/.serena/serena_config.yml にプロジェクトフォルダーが登録されます）

設定ファイルの生成

uvx --from git+https://github.com/oraios/serena serena project generate-yml

👉 プロジェクトフォルダーに .serena/project.yml が生成されるので、

  • language: csharp

等の設定をざっと確認します。

👇 公式のテンプレート

https://github.com/oraios/serena/blob/main/.serena/project.yml

プロジェクトのインデックス生成

uvx --from git+https://github.com/oraios/serena serena project index

👉 C# プロジェクトだとエラーが出ますが、出ても問題ないようです。（2025/08/02 時点）

Serena 導入の効果

トークンの圧縮効果

Serena や VS Code が使う LSP（Language Server Protocol）は単なるシンタックスハイライトに留まらず、メソッドやプロパティーの参照を正確に把握したりシンボルの名前を参照先を含めて変更する等、現代のソースコードエディターにあって当然の機能の全てを提供しています。

Serena を使わない場合、AI エージェントはそれらモダンな編集機能の恩恵を受けられないので、「○○行目を△△に置き換えて、次は……」といった命令を大量に発行して力技でファイルを編集します。呼び出しが多いメソッドをリファクタリングする等の場合は発行する命令の数が増えるので、必然的にトークンその他の消費量が増えます。

導入後は sed を使った職人技的なモノを生成するというステップが無くなり単純な MCP ツール呼び出し一つですべてが片付くようになるので、コードベースが大きければ大きいほど効果が大きく Kiro 経由で Claude を使っていても恩恵を受けられます。

Claude Code の性能低下の原因

Claude Code がダメになったと言われている原因（推測）は、サーバー側の記憶容量にクォータが設定された、またはセッション単位の制限だったものがユーザーアカウント単位に変更された為だと思います。（並列で２４時間エージェントを回し続ける人対策）

Claude は「アホになった」と言われる前から前回のチャットセッションを全く覚えていませんでした。上記の Agent Steering に書いてある csc を使うなという指示も、（アホになる前から）再起動すると過去の指示を全部忘れていたので書くようになったという経緯があります。

ですがチャットの履歴とは違い、アホになる前の Claude はプロンプトを積み上げた結果であるソースコードはほぼ無制限でサーバーに保存していたんだと思います。

なので「○○を実装して」という単純なプロンプトでも、「それまでの積み重ねであるコードベース全て」に基づいて似たようなスタイル／デザインパターンの結果を出力できていて、そしてそれはとても頭が良く見えたわけです。

記憶容量が制限された現在では一部のソースコードしかサーバーに保存されていないので「○○を実装して」という単純な指示を受けると、他の部分と全く整合性が取れていない、ありものだけを参照したアホな結果を出力する事になってしまっているわけです。

印象ベースですが Claude の性能自体は今までと変わらないです。これまでもプロジェクトの初期には「なんだこれ？」なコードを出力するので、それを修正する為の指示を出していたハズです。ですが仕様変更前はコードベース全体を保存していたので「間接的に」過去の指示を記憶しているような状態でした。アホになった現在は常にプロジェクト初期と同じ状態なので毎回「なんだこれ？」なコードを生成します。それを防ぐには適切な指示を毎回行わなければならなくなっただけです。

Serena 導入の効果

Serena を導入すると AI エージェントはコード生成に関わる記憶を write_memory を使ってローカルファイルに保存するようになります。

出力された記憶の例（アーキテクチャ欄がアーキテクチャでも何でもなくて笑うｗ）

## Architecture Pattern
- **Source Generator Pattern**: Implements `ISourceGenerator` interface
- **Syntax Receiver Pattern**: Uses `ISyntaxReceiver` for collecting candidates
- **Builder Pattern**: Uses StringBuilder for code generation
- **Strategy Pattern**: Different generation strategies for different target types

## Generated Code Features
- **Nullable Reference Types**: Generated code includes `#nullable enable`
- **XML Documentation**: All generated members include XML docs
- **Generic Type Support**: Handles generic types with proper constraints
- **Accessibility Modifiers**: Respects original type accessibility

これらのチャット履歴の積み上げは Claude Code を使っているなら恩恵があるのかも？ という感じです。前述のクォータ制限による記憶力低下を補ってくれる可能性があります。

ただ、上記の通り内容がめちゃくちゃなので効果は限定的なのでは？ とも思います。（StringBuilder というクラスはビルダーパターンとは全く関係ないです）

もし Serena を導入しても効果が薄いと感じる場合は read_memory を使うよう明確に指示した方が良いと思います。呼び出し頻度が低い場合、プロンプトを積み上げた結果の知識を上手く使えていない可能性があります。

Kiro の場合

Kiro では先に挙げたようなドキュメントを仕様駆動開発の一環として最初にガチガチに固めます。なので Serena で賢くなるとかは無いと思います。

（そういう意味では無意味ですが、トークン圧縮の恩恵を受けられる可能性が高いので導入はした方が良いと思います）

ちなみに手元の Kiro 環境では write_memory だけ行い read_memory は行っていませんでした。めちゃくちゃな記憶内容なので使わないのが正解ではあります。ナイス！

Claude Code（Kiro 以外）の場合

記憶として書き出されるドキュメントを見てみると、コーディングスタイル以外の内容は間違ってないけどめちゃくちゃで下手したらマイナスになりかねない印象です。

ただ、Kiro と違って雑な指示でもある程度動いてしまっていた Claude Code に限れば、勝手野放図にコード生成する状態から「めちゃくちゃとはいえ指針がある状態」になるので多少賢くなったように感じるかもしれません。

おそらくですが、より良い結果を得たいなら出力された .serena/memories の内容を自分で書き換えたほうが良いと思います。マジで内容がめちゃくちゃなので。

余談（C#）

C# プロジェクトと Claude（Kiro）の相性はあまり良くないです。というのもテスト駆動開発が前提となっていて、

  1. 小さなコンポーネントを作る
  2. 単体テストを作って通す
  3. 1 に戻る

を繰り返して徐々に全体を作り上げていくんですが、とにかく「小さなコンポーネント向けの単体テスト」を書くのが Claude は下手で、

csc unit-test.cs /r:src/bin/Debug/**/something.dll

みたいな処理を頻繁に書いては失敗します。なので csc（C# 5.0 までしか対応していない） を使うなという指示、または csc にパスを通すのが必須になります。

ちなみに AI 自身が最初に作った TestApp という単体テストプロジェクトが存在する場合でも、それを使おうとはせず毎回新規に書き起こす謎行動。毎回ではないんですが、テストを通した後にテストスクリプトを削除したりする等も。

最新の .NET SDK なら dotnet run unit-test.cs で単体テストを単一ファイルアプリとして実行可能なんですが、現段階ではエージェント側の学習が済んでいないので下手に指示すると dotnet-script を使ったり .csx ファイルを生成しようとしたりします。

👉 なのでこんな要望を出してみた https://github.com/dotnet/sdk/issues/49985

コンテキストを限定するという意味では単体で動くアプリで特定の対象のみをテストする、というのは完全にアリなんですが C# のテスト用インフラがテスト駆動開発と相性が悪いというか何というか。。。ちゃんとし過ぎているんですよね。C# は Java フォロワーなのでエンタープライズ向け感が拭えず、しかし dnx のように node 感も出そうとしている真っ最中なのでうーーん状態。色々と定まらず。

※ ちなみに Claude が単体テストのビルドエラーすら直せない時は dotnet を英語設定にすると解決します。

https://x.com/sator_imaging/status/1950417866114945284

おわりに

Serena を導入すると AI エージェントが積み上げたプロンプトを仕様書っぽい文書として出力するようになるので、Vibe コーディングならぬ Vibe 仕様駆動開発が行えるようになるといった感じでしょうか。

そもそも、最初にガチガチに仕様を固める Kiro においては Serena の効果は限定的で下手をすればマイナスです。せっかく書いた仕様書が汚染されないように read_memory だけツールから除外するのも選択肢としてアリでしょう。

（トークンの圧縮という点では恩恵を受けられるので Serena 自体は良いものです。使った方が良いです）

AI 向けツールは色々と登場しますが、結局コーディングエージェントの正しい使い方は Amazon Kiro が見出した仕様駆動開発に帰結するという感じですね。マジで捗りますからねアレ。

以上です。お疲れ様でした。

Discussion