gentle-ai レビュー: 既存のコーディングエージェントに設定一式を後付けする Go 製コンフィギュレータ
Gentle-AI configures the AI coding agents you already use: Claude Code, Cursor, OpenCode, Codex, Pi, and more. Choose persistent memory, Spec-Driven Development, curated skills, MCP servers, personas, and optional bounded review. Open source, no agent lock-in.
ひと目でわかる
- これは何？
- Claude Code、Cursor、OpenCode、Codex など既に入っているエージェントを対象に、永続メモリやスキル、MCP サーバ、ペルソナを選択式で組み込むツール。エージェント本体は一切インストールしないという設計方針と、その代わりに生じる制約を README から読み解く。
- 誰に向いている？
- 毎日エージェントを使っていて、セッションをまたぐ記憶やレビュー証跡の欠如に手を焼いている個人開発者、および複数ランタイムで挙動を揃えたいチームには向く。逆に、エージェントをまだ入れていない人、設定ファイルを自前で書きたい人、gentle-ai が検出できないランタイムしか使っていない人には不要である。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
エージェントを置き換えるのではなく、設定するという立場
gentle-ai が解こうとしているのは、モデルの性能ではなく設定の不在である。README の冒頭は、エージェントが「セッション間ですべてを忘れ、プロジェクトの成り立ちに意見を持たず、自分の仕事を確認する手段を与えない」と述べ、これを導入前の状態として提示する。つまり対象読者は、すでに Claude Code、Cursor、OpenCode、Codex、Pi のいずれかを日常的に使っている開発者だ。エージェントを初めて導入する人向けのツールではない。
この立場は README の警告ブロックで明示される。gentle-ai はエージェントを決して自動インストールしない。選択したエージェントを検出できなければ処理を拒否し、利用者自身が実行すべきコマンドを表示する。マシン上に黙ってソフトウェアを入れることはない、という宣言である。設定ツールが依存関係を勝手に解決してくれる方が便利だと感じる人には、この設計は回りくどく映る。だが、複数のエージェントを併用している環境では、どのツールが何を入れたのか分からなくなる事態を避けられる。トレードオフとして受け取るべきはこの点だ。利便性を捨てて、変更の所在を追跡可能にしている。
コンポーネント選択という構成単位
gentle-ai は機能を一枚岩で提供しない。README は提供物をコンポーネントの集合として列挙し、個別に選ぶかプリセットでまとめて取るかを選ばせる。
推奨として示されるのは Engram と Skills の二つ。Engram はセッションをまたぐ永続メモリで、意思決定、バグ修正、文脈が再起動後も残ると説明される。Skills はタスクが条件に合致したときにエージェントが読み込む、厳選されたコーディングスキルのライブラリである。
任意扱いなのは Persona、SDD、Context7、Permissions、GGA、Theme。Persona は教えることに寄せた語り口か中立、あるいは自作。SDD はまとまった機能に向けた計画ワークフロー。Context7 はフレームワークやライブラリの最新ドキュメントを取得する MCP サーバ。Permissions は ~/.ssh、.env、認証情報ファイルを含む拒否リストを備えたセキュリティ寄りのガードレール。GGA は Gentleman Guardian Angel という AI プロバイダ切り替え。Theme は Claude Code と OpenCode 向けの配色である。
推奨と任意の線引きは、そのまま導入時の判断コストになる。永続メモリとスキルは入れて当然という前提が README の書きぶりから透けるが、Permissions のような安全装置が任意扱いなのは気にかかる。deny list の対象が ~/.ssh と .env と認証情報ファイルである以上、これを入れない構成は攻撃面を広げる。プリセットの内容は README の表が途中で切れており、どのプリセットが何を束ねるかは全文では確認できない。
導入は対話式の一コマンドから
README の Quick start は二つのコマンドだけを示す。まずエージェント、コンポーネント、ペルソナを選ぶために引数なしで実行する。
gentle-ai
次にインストール結果を検証する。
gentle-ai doctor
前提条件とプラットフォーム別のバイナリコマンドは Install セクションに分離されており、README の抜粋にはその中身が含まれていない。macOS、Linux、Windows のバッジはあるが、具体的なインストールコマンドはこの資料からは確認できない。Go 1.25.10 以上が要求される点はバッジから読み取れる。
設定キーについても、README の抜粋にはコンポーネント名以外の具体的なキーが現れない。Permissions の deny list がどのファイルでどう記述されるか、Engram の保存先がどこか、といった情報はこの範囲では不明である。導入を検討するなら、Install セクションと Reference セクションを原文で確認する必要がある。ここで確認できるのは、設定が対話式の選択を通じて行われるという流れだけだ。
エージェントが仕事の進め方を決めるまで
README には「How your agent decides how to work」という節がある。エージェントが作業方針をどう決めるかという問いを立てている点が、単なる設定配布ツールとの違いを示す。
関連する仕組みとして SDD と RDD が挙げられる。SDD は Spec-Driven Development で、まとまった機能に向けた計画ワークフローと説明される。RDD は Receipt-Driven Development で、v2.6.0 のリリース名が「The Runtime Asks First」であることから、実行時に何らかの確認を挟む方向へ舵を切ったことがうかがえる。README の導入文にも「任意の、境界づけられたレビュー」という表現があり、レビュー工程が無制限に走るのではなく範囲を限定する設計であることが読み取れる。
ただし、SDD と RDD が具体的にどのファイルを生成し、どのタイミングでエージェントを止めるのかは、この資料からは分からない。v2.6.0 から v2.7.0 までの間隔が約四日である点も、変化の速さとして記録しておく。仕様駆動や証跡駆動という言葉だけが先行しがちな領域なので、導入前に実際の生成物を確認したい。
エージェントを検出できないときの挙動
gentle-ai の最も明確な制約は、対応ランタイムが既に存在していることを前提とする点である。README は Claude Code、Cursor、OpenCode、Codex、Pi などを挙げるが、これは網羅的なリストではなく「and more」と濁されている。
検出できなかった場合、gentle-ai は拒否して、利用者自身が実行すべきコマンドを表示する。つまり失敗の形が親切ではあるが、失敗であることに変わりはない。社内で独自にビルドしたエージェントや、README に名前のないランタイムを使っている場合、このツールは何もしてくれない。
もう一つの制約は、複数エージェントの設定を一括で同期する仕組みが README からは読み取れないことだ。チームで挙動を揃えたいという用途は挙げられているが、設定をリポジトリにコミットして配るのか、各自が対話式に選ぶのかは不明である。対話式の選択が前提なら、メンバーごとに選んだコンポーネントがずれる余地が残る。この点は導入前に確認すべき項目として残る。
代替手段との違い: 何を設定するかの粒度
比較対象として分かりやすいのは、各エージェントが標準で持つ設定ファイルを手で書く方法である。Claude Code にも Cursor にも、プロジェクト指示や MCP サーバを記述する場所は用意されている。
違いは抽象度にある。手書きの場合、エージェントごとに書式が異なるため、Claude Code 用と Cursor 用に同じ意図を二度書くことになる。gentle-ai はこの差分を吸収し、コンポーネントという共通の語彙で複数ランタイムに同じ構成を適用しようとする。設定の意図を一箇所で決めたい人には利点になる。
逆に、手書きの方が向く場面もある。エージェントの設定ファイルはバージョン管理に置けて差分レビューできる。gentle-ai が生成する設定がどの程度そのまま読める形なのかは、この資料からは判断できない。生成物が機械的なものであれば、差分レビューのしやすさでは手書きに劣る可能性がある。もう一つの代替は、永続メモリだけを目的とした専用ツールの利用だが、gentle-ai はメモリ、スキル、MCP、ペルソナを一つの選択画面にまとめている点で性格が異なる。
ライセンスと保守の見通し
ライセンスは MIT で、リポジトリのバッジにも LICENSE ファイルにもその表示がある。MIT は商用利用を含めて制限が緩い条件として広く知られるが、具体的な義務や同梱物の扱いは利用形態によって変わるため、ここで法的な判断はしない。配布物にライセンス表示を残す必要があるかどうかは、自組織の法務や既存のポリシーで確認する項目である。
保守コストの観点で資料から言えるのは、更新の頻度が高いという事実だ。v2.6.0 が 2026-09-04、v2.7.0 が 2026-09-08 で、その間にリリース候補版が挟まる。README には「Keeping it up to date」という節が用意されているが、その中身は抜粋に含まれない。更新コマンドの実体は確認できない。
Go 1.25.10 以上という要求も見逃せない。Go のマイナーリリースは比較的速い周期で上がるため、ビルド済みバイナリを配布する形なのか、ソースからビルドする前提なのかで負担が変わる。バイナリの入手方法は Install セクションの確認事項である。
導入を決める前に確かめること
gentle-ai の価値は、エージェントの性能を上げることではなく、設定の抜けを埋めることにある。README が「Before」と「After」の対比で示すのは、記憶、規約の遵守、タスク規模に応じた作業スタイル、レビュー可能な証跡の四点である。この四点のうち、どれが自分の困りごとかを先に決めた方がよい。
最初に実行するのは gentle-ai doctor になる。ただしこれはインストール後の検証コマンドであり、事前に対象ランタイムが検出されるかを確かめる手段があるかは、この資料からは分からない。コンポーネントを個別に選べる以上、Engram だけ入れて様子を見る、Permissions だけ入れて deny list の挙動を確認する、といった段階的な導入が可能であることは README の構成から読み取れる。
判断が割れるのは Permissions の扱いだ。任意コンポーネントとして並んでいるが、~/.ssh と .env を拒否する設定を入れない理由は多くの場合ない。逆に、既存の設定ファイルに独自の拒否ルールを書いている人は、二重管理になる可能性を確認したい。README にはアンインストールやロールバックの記載が見当たらないため、導入前に設定ファイルのバックアップを取っておくのが現実的な備えになる。
編集部の結論
毎日エージェントを使っていて、セッションをまたぐ記憶やレビュー証跡の欠如に手を焼いている個人開発者、および複数ランタイムで挙動を揃えたいチームには向く。逆に、エージェントをまだ入れていない人、設定ファイルを自前で書きたい人、gentle-ai が検出できないランタイムしか使っていない人には不要である。導入前に確認すべきは、対象ランタイムが検出可能かどうかを gentle-ai doctor で確かめること、そして Permissions コンポーネントの deny list が自分のプロジェクトのパス構成と衝突しないかである。README にはコンポーネントごとのアンインストール手順が見当たらないため、設定を戻す手段を先に把握しておきたい。
コミュニティノート