Renma というツールを作っています。
まだ大きなプロジェクトではありません。
npm に公開して、少しずつ機能を足しながら、自分の考えている方向性が本当に形になるのかを検証している段階です。
ただ、0.5.0 まで進んだら、一度きちんと文章にしておきたいと思っていました。
Renma は単なる Markdown lint ではなく、また、LLM を呼び出す agent framework でもありません。自分の中では、LLM 時代に必要になるであろう Context Repository、あるいは context asset の品質を保つための Git-native な governance tool として考えています。
この記事では、なぜ Renma を作っているのか、何を解こうとしているのか、そして 0.5.0 時点でどこまで来たのかを書いてみます。
Prompt Engineering の次に必要になるであろうもの
LLM を使う開発体験は、この数年で大きく変わりました。
以前は「どう prompt を書けばよいか」が中心だったように思えます。
よい prompt を書けば、よい出力が得られる。これは今でも正しいと思います。
一方で、実際に LLM を仕事や開発の中で使っていくと、prompt だけでは足りない場面が増えてきます。
たとえば、あるチームのテスト設計を LLM に手伝わせたいとします。
そのときに必要なのは、単なる一般的な事柄だけではありません。
そのプロダクトで重要視している品質基準、過去に問題になった仕様、レビュー時に見落としやすい観点、チーム固有の用語、関連するドキュメント、避けるべき判断、使ってよいツール、完了条件などが必要になります。
これらは、単発の prompt に毎回手で書くには大きすぎます。
一方で、雑に長いドキュメントを全部渡せばよいわけでもありません。
LLM に渡す context は、多ければよいわけではありません。
むしろ、適切な粒度で分割され、所有者があり、参照関係が明確で、いつ使うべきかが分かる形になっている必要があります。
このあたりに、自分はかなり強い関心を持っています。
Context は資産として管理されるべきではないか
ソフトウェア開発では、コードは Git などで管理します。
変更履歴があり、レビューがあり、CI があり、責任の所在があります。
しかし、LLM に渡す知識や判断基準はどうでしょうか。
多くの場合、それらは README、Confluence、Google Docs、GitHub Issues、Pull Request、Slack の会話、個人の頭の中などに散らばっています。
そして LLM に何かを頼むとき、人間がその場で必要そうな情報を探し、貼り付け、説明し直しています。
これは短期的には便利です。
ただし、組織やプロジェクトが大きくなると、だんだん限界が見えてきます。
「この context は本当に今も正しいのか」
「この skill はどの context に依存しているのか」
「このドキュメントを変えたら、どの LLM workflow に影響するのか」
「この知識は誰が owner なのか」
「LLM がこの task を実行するには、何が足りないのか」
こういった問いに答えられないまま、LLM の活用だけが進むと、prompt や workflow は徐々に属人化していきます。
自分が Renma でやりたいことは、この部分です。
LLM に渡す context を、一時的な prompt の材料ではなく、継続的に育てる context asset として扱いたい。
そして、その context asset を Git repository の中で管理し、検証し、改善し続けられるようにしたい。
Renma とは何か
Renma は、LLM-ready な skills や shared context assets を持つ repository のための、Git-native な governance / quality CLI です。
少し長い説明ですが、意図的にこう表現しています。
Renma の中心には、主に二つのものがあります。
ひとつは skill です。
これは LLM への入り口です。つまり、LLM や agent に対して「この task を実行するときは、こういう目的で、こういう入力を受け取り、こういう context を参照し、こういう完了条件を満たしてほしい」と伝えるための単位です。
もうひとつは context です。
これは、LLM が task を実行するために参照する source-of-truth 的な知識資産です。設計方針、テスト観点、ドメイン知識、運用ルール、レビュー基準などがここに入ります。
Renma は、これらの skill や context を読み取り、catalog、ownership、graph、readiness、diagnostics などを deterministic に出力します。
重要なのは、Renma 自体は LLM を呼び出さないということです。
Renma は agent ではありません。
prompt wrapper でもありません。
runtime で最適な context を自動選択する仕組みでもありません。
ダッシュボードやサーバーを中心にしたサービスでもありません。
Renma がやるのは、その前段階です。
LLM や agent が動くための環境を整える。
その repository にある skill や context が、LLM に渡す資産として十分に扱える状態かどうかを検査する。
問題があれば、人間にも LLM にも分かる形で診断を出す。
自分の中では、ここが Renma の立ち位置です。
なぜ deterministic であることにこだわるのか
LLM のためのツールなのに、Renma の core は LLM を呼び出しません。
これはかなり意識的な設計です。
LLM は強力ですが、品質管理の土台まで LLM に任せると、検査結果そのものが揺らぎます。
もちろん、LLM を使って改善案を出したり、診断結果を元に patch を作ったりするのは有効です。むしろ、そこはかなり相性が良いと思っています。
ただし、少なくとも core の scan や validation は、同じ repository に対して同じ結果を返してほしい。
CI に載せられる必要があります。
Pull Request で差分を見られる必要があります。
「なぜこの skill は ready ではないのか」を、reviewable な形で説明できる必要があります。
そのため、Renma の core は deterministic である必要があるのでは、と考えています。
たとえば、Renma が診断結果を出し、Codex や Claude のような coding agent がそれを元に repository を修正し、人間が review し、再度 Renma を実行する。
この流れはかなり自然です。
しかし、その流れの起点になる診断は、できるだけ安定しているべきです。
Renma は LLM の代わりに考えるツールではありません。
LLM がより安全に、より再現性高く働くための地面を整えるツールです。
ただの Markdown lint ではない
Renma を外から見ると、最初は Markdown lint のように見えるかもしれません。
ファイルを読み、metadata を検査し、足りない項目を指摘する。
その意味では、たしかに lint 的な側面はあります。
ただ、自分が Renma でやりたいことは、一般的な Markdown の整形ではありません。
Renma が見たいのは、「この文章が Markdown として正しいか」ではなく、「この context は LLM-facing な asset として使える状態か」です。
たとえば、次のような観点です。
- この context は何のためのものか
- 誰が owner なのか
- どの skill から参照されるのか
- 依存関係は解決できるのか
- 古くなった reference はないか
- task を完了するための条件が明確か
- 必須入力が曖昧ではないか
- LLM が使うには大きすぎないか
- 他の context と重複していないか
- 修正すべき場合、どこをどう直せばよいか
これは、文章の style を揃える話ではありません。
LLM が使う知識を、長期的に運用できる形にする話です。
その意味で、Renma はかなり opinionated なツールです。
すべての organization に対して中立な抽象ツールを目指しているわけではありません。
むしろ、「LLM に渡す context は、こういう性質を持っていた方がよい」という自分なりの考えを、CLI と diagnostics に落とし込んでいます。
すべてを Renma に保存したいわけではない
もうひとつ大事にしているのは、Renma を巨大な knowledge store にしないことです。
チームにはすでに source of truth があります。
GitHub、Confluence、Google Docs、ADR、issue tracker、既存の docs などです。
Renma は、それらを全部コピーして自分の中に閉じ込めたいわけではありません。
むしろ、Renma は context asset と references を管理するものだと考えています。
必要な知識が外部にあるなら、その link を references として持てばよい。
大事なのは、LLM-facing な skill や context から、その source of truth に辿れることです。
LLM に必要な知識をすべて一箇所に text として詰め込むのではなく、どこに何があり、どの task で何を参照すべきかを管理する。
この traceability が重要だと考えています。
一般的な知識であれば、そこまで厳密な traceability はいらないかもしれません。
ネットで簡単に見つかる情報に、わざわざ reference を積み上げる価値は小さいでしょう。
しかし、特定のドメインやチームに閉じた知識では話が違います。
暗黙的には分からない判断基準、過去の経緯、設計上の制約、レビュー時の観点などは、きちんと context asset として扱う価値があります。
Renma は、そのための repository を作りたいのです。
0.5.0 でどこまで来たか
0.5.0 は、Renma にとって「完成版」ではありません。
ただ、自分の中では、方向性を外に説明するには十分な節目だと思っています。
0.1.0 では、まず CLI としての基本的な形を作りました。
scan、catalog、ownership、graph、readiness、inspect など、repository にある skills や context assets を deterministic に読み取り、状態を確認するための土台です。
その後の version では、実際に dogfood しながら、diagnostics の質、dependency/reference の扱い、readiness の表現、semantic diff、docs と実装の同期などを少しずつ改善してきました。
0.5.0 では、特に次の点を意識しています。
- Renma が何をするツールなのかを README と docs でより明確にする
- skill / context / references の考え方を example として示す
- docs と CLI の挙動がずれにくいようにする
- repository の状態を CI や review の中で確認しやすくする
- diagnostics を、人間だけでなく coding agent にも扱いやすい形にする
ここまで来ると、Renma は単に「手元で試せる CLI」ではなく、継続的に context repository を運用するための入口になってきます。
もちろん、まだ足りないものはたくさんあります。
よりよい example repository、実際の workflow との統合、外部 reference の扱い、semantic diff の表現、agent と組み合わせた修正 loop など、やりたいことは多いです。
それでも、0.5.0 は一つの区切りです。
Renma が何を目指しているのかを、そろそろ外に向けて説明してよい段階に来たと思っています。
モデルやツールが変わっても残るもの
AI tool の世界は変化が速いです。
今便利な tool も、数ヶ月後には別の tool に置き換わっているかもしれません。
今強い model も、いずれ新しい model に抜かれるでしょう。
agent framework も、IDE integration も、server-side の workflow も、これから何度も変わると思います。
その中で、自分が比較的長く残ると考えているのが context asset です。
プロダクト固有の知識。
チームの判断基準。
レビュー観点。
運用ルール。
過去の失敗から得た制約。
設計やテストのための shared knowledge。
これらは、model が変わっても価値が残ります。
むしろ model が賢くなるほど、良い context を渡せるかどうかの差が大きくなるかもしれません。
だからこそ、context をその場限りの prompt として消費するのではなく、育てる対象として扱いたい。
Renma はそのための試みです。
Renma という名前について
Renma は「練磨」から来ています。
知識や技術を、一度作って終わりにするのではなく、少しずつ磨いていく。
LLM に渡す context も同じだと思っています。
最初から完璧な context repository を作ることは難しいです。
むしろ、使いながら問題を見つけ、分割し、owner を明確にし、reference を足し、不要な重複を減らし、より使いやすい形にしていく。
その積み重ねが重要です。
Renma は、そういう「磨き続ける」ためのツールにしたいと思っています。
これから
Renma はまだ実験的なプロジェクトです。
ただ、自分の中ではかなりはっきりした問題意識があります。
LLM を本格的に使っていくなら、prompt だけでは足りない。
agent だけでも足りない。
server-side の workflow だけでも足りない。
その前に、LLM が参照する context の品質をどう保つか。
チームやプロジェクトの知識を、どう再利用可能な asset として育てるか。
そして、それを Git-native に、reviewable に、deterministic に扱えるか。
Renma は、この問いに対する自分なりの答えです。
0.5.0 は、その最初のまとまった形だと思っています。
まだ荒いところもありますが、ここからさらに dogfood しながら、LLM 時代の context repository として育てていきます。
興味があれば、ぜひ repository や npm package を見てみてください。
~ my tech diary ~ 