Fulling v3 を採用する前に読む: kubeconfig 平文保存という境界線

Fulling が解こうとしているのは「毎回作り直されるエージェント環境」の問題

Fulling の README は、プロジェクトの狙いを「専用の AI ワークスペース」、つまりスキル、ファイル、メモリ、スクリプト、ランタイムを組み合わせた永続的な環境の構築だと説明している。エージェントに毎回コンテキストを読み込ませるのではなく、環境そのものを保持するという発想だ。ただし現行の v3 が提供しているのは、その製品モデルに必要な「アイデンティティと Kubernetes 資格情報の境界」までである。対象読者は、Kubernetes をインフラとして使いながら、エージェントに実行環境を渡す仕組みを内製しようとしている開発者だ。完成品のエージェント製品を探している読者には、このリポジトリはまだ答えを出していない。

v3 の実装範囲は認証と kubeconfig の受け渡しに絞られている

現在の基盤として README が挙げているのは、Better Auth による GitHub 限定のサインイン、PostgreSQL に保存されるユーザー、プロバイダーアカウント、セッション、保護されたワークスペースの入口、ユーザーごとに 1 つの平文 kubeconfig、Kubernetes の SelfSubjectReview を使った認証済み kubeconfig の検証、そしてユーザー単位にスコープされた Kubernetes クライアント境界である。データの流れは単純で、サインインしたユーザーが kubeconfig を登録し、アプリケーションが SelfSubjectReview でそれを検証し、以降はその資格情報で Kubernetes API を呼ぶ。エージェントの推論やツール実行のループについては、この README には記述がない。v3 はエージェント本体ではなく、その手前にある認可と資格情報の層だと考えたほうが実態に近い。

kubeconfig は PostgreSQL に平文で保存される

README の Credential Boundary の節は明快だ。kubeconfig は PostgreSQL に平文で保存され、データベースの読み取り権限があればユーザーの Kubernetes 資格情報に到達できる。ブラウザ向け API は保存済みの内容を返さず、ログにもトークン、鍵、証明書、kubeconfig の中身を出してはならないとされている。つまり防御は「API とログに漏らさない」ことに寄っており、保存時の暗号化には触れていない。データベースのバックアップ、レプリカ、あるいは読み取り権限を持つ別サービスが侵害された場合、影響はそのまま Kubernetes クラスタへの到達可能性になる。この設計を受け入れられるかどうかが、採用判断の最初の分岐点になる。

検証で弾かれるものと、意図的に弾かれないもの

kubeconfig の検証は、実行可能な credential plugin、auth-provider plugin、ローカルファイルを参照する credential フィールド、プロキシ設定、非 HTTPS の API サーバー、リダイレクト、匿名アイデンティティを拒否する。一方で、認証済みユーザーが任意のネットワークアドレス上に HTTPS の API サーバーを設定することは許容される。README はこれを「認証済みの外向きリクエスト、すなわち SSRF の境界であり、明示的なデプロイ判断である」と位置づけている。プラグイン経由の任意コード実行や平文 HTTP は塞ぎつつ、認証済みユーザーが内部アドレスを指す HTTPS エンドポイントを登録する余地は残る。マルチテナントで公開するなら、この残余リスクをどう扱うかをデプロイ側で決める必要がある。

起動手順: 公開アプリと旧認証ワークスペースで必要なものが違う

要件は Node.js 24 と、それに同梱される npm 11 である。公開アプリケーションは PostgreSQL も OAuth プロバイダーも必要としない。ローカルでは npm ci のあと npm run dev を実行すると、サインインを無効にした状態で公開アプリが起動し、http://localhost:3000 で確認できる。旧来の認証付きワークスペースを動かす場合は、cp .env.template .env.local でファイルを用意し、データベース、Better Auth、GitHub の各値を埋めてから npm run prisma:migrate と npm run dev を実行する。GitHub OAuth のコールバックは ${BETTER_AUTH_URL}/api/auth/callback/github に設定する。コマンドは npm run build、npm run lint、npm test（Vitest）、npm run test:e2e（Playwright）、npm run prisma:format、npm run prisma:validate、npm run prisma:migrate が用意されている。Vercel では vercel.json なしのネイティブ Next.js デプロイが使え、公開アプリは環境変数なしでビルドと起動ができるが、GitHub サインイン、データベースを使うワークスペース、kubeconfig の各フローは、旧構成の設定が完全に揃うまで無効のままだと README は説明している。

v2 からの移行はできず、Kubernetes 側のリソースは残る

このリリースは新しいベースラインスキーマを使うため、新しいデータベースか、明示的にリセットしたデータベースに対して実行する必要があり、v2 のデータは移行しない。README はリポジトリに旧製品モデルや旧認証方式との互換レイヤーを意図的に含めていないと書いている。加えて、v2 のデプロイを置き換える前に docs/v2-resource-inventory.md に従うよう求めている。理由は明確で、Fulling のデータベースをリセットしても、v2 が作成した Kubernetes リソースは削除されないからだ。アプリケーション側をきれいに作り直しても、クラスタ側には前のバージョンが残したワークロードや名前空間が残る。移行を計画しているなら、この 2 つの面を別々に扱う必要がある。

比較対象としての Claude Code と、汎用エージェント基盤

同じ課題に対するアプローチは 2 つに分かれる。Claude Code のようなローカル CLI 型は、開発者のマシン上の資格情報とファイルシステムをそのまま使い、状態はローカルに置く。サーバー側で資格情報を預かる必要がなく、kubeconfig をデータベースに保存する問題自体が発生しない。代わりに、環境は開発者のマシンに閉じる。もう一方の LangGraph や Dify のような汎用エージェント基盤は、ワークフローやツール呼び出しの抽象化を提供するが、Kubernetes の資格情報境界や SelfSubjectReview による検証は自前で用意することになる。Fulling はこの中間に位置し、永続ワークスペースという製品像に対して、認証と Kubernetes 資格情報の層だけを先に実装した状態だ。どの層を自分で書きたくないかで選ぶべきであって、機能の多さで比べる類のものではない。

ライセンスと維持コスト

ライセンスは MIT で、リポジトリはアーカイブされておらず、最終 push は 2026-08-17、直近のリリースは v2.0.0（2026-05-11）と v1.0.0（2026-01-30）である。README が説明する v3 は、これらリリースとは別に main ブランチ上で進行している基盤だという点に注意したい。MIT は商用利用や改変を許容するが、この点は法的助言ではないので、実際の運用条件は自組織で確認してほしい。維持コストとして見ておくべきは、v2 から v3 へのスキーマ非互換、旧認証方式との互換レイヤーが存在しないこと、そして docs/architecture.md に書かれた目標の Workspace モデルと現行実装との差を自分で埋める必要があることだ。アップグレードはデータの引き継ぎではなく、新しいデータベースへの再構築として計画することになる。

編集部の結論

Fulling を検討すべきなのは、Kubernetes 上で動く AI エージェント用ワークスペースの土台を自前で組み立てる前提があり、PostgreSQL の読み取り権限がそのままユーザーの Kubernetes 資格情報へのアクセスになることを受け入れられるチームだ。逆に、既存の v2 環境をデータごと引き継ぎたい場合や、認証付きワークスペースを本番でそのまま公開したい場合には向かない。最初に確認すべきは、docs/architecture.md に書かれた目標の Workspace モデルと、いま実装されているユーザー単位 kubeconfig の差分がどこまで埋まっているか、そして docs/v2-resource-inventory.md に従って v2 が作成した Kubernetes リソースを洗い出せるかどうかである。データベースをリセットしても、v2 が作った Kubernetes 側のリソースは消えない。

公式情報源

1. FullAgent/fulling on GitHub
2. License: MIT
3. Project website
4. README
5. Releases