本文へスキップ
hdknr blog
戻る

Claude Code は『賢いが健忘症のプログラマ』— Trellis でプロジェクトの脳を持たせる

「AI コーディングは不安定だ」とこぼす前に、まず疑うべきは Claude そのものではなく、毎回 AI を「記憶喪失のまま出社させている」自分の運用かもしれない。X で話題になった Amto (@XAMTO_AI) の投稿 は、この問題を端的に言い表している。Claude Code を単体で使うと「賢いが健忘症のプログラマ」にすぎないが、Trellis を組み合わせると初めて『AI 開発チーム』らしくなる、というのだ。

この記事では、その Trellis(mindfold-ai/Trellis)が何を解決するツールなのか、どう動くのか、どうやって導入するのかを整理する。

なぜ毎回「ゼロから説明」になるのか

Claude Code をはじめとする AI コーディングエージェントは、セッションをまたいで文脈を保持しない。だから新しいセッションを開くたびに、開発者は同じ作業を繰り返すことになる。

  1. プロジェクトの背景をもう一度説明する
  2. 要件をもう一度読み込ませる
  3. コーディング規約をもう一度読み上げる
  4. 「前回どこまでやったか」をもう一度解説する

人間の同僚に毎朝これをやらされたら誰でも嫌になる。AI も同じで、文脈が欠けたまま走り出すから出力がブレる。「AI が不安定」の正体は、多くの場合文脈の供給が不安定だということだ。

Trellis はこの一点を潰すために生まれている。プロジェクト内に .trellis/ ディレクトリを作り、要件・規約・タスク・進捗・作業ログをすべてリポジトリに沈殿させる。次に Claude Code が入ってきたとき、こちらが説明しなくてもエージェント自身がその文脈を読み、「このプロジェクトは何をするもので、どこまで進んでいて、次に何をすべきか」を把握した状態でスタートできる。

Trellis とは何か

Trellis は mindfold-ai が開発する、AI コーディングのためのエンジニアリング・フレームワークだ。単なるプロンプトテンプレート集ではなく、「計画 → 実装 → 検証 → 学びの書き戻し」という一連の開発ワークフローそのものを仕組み化している点が特徴である。

GitHub リポジトリは執筆時点で 1 万 stars 超、ライセンスは AGPL-3.0。Claude Code だけでなく Cursor、Codex、OpenCode、Gemini CLI など複数のコーディングプラットフォームに対応するマルチプラットフォーム設計になっている。

公式は Trellis を「最高のエージェント・ハーネス(the best agent harness)」と表現している。ここでいうハーネスとは、AI エージェントが安定して働けるよう周辺を固める「足場・実行環境」のことだ。

.trellis/ ディレクトリ — プロジェクトの脳

Trellis を初期化すると、リポジトリ直下に .trellis/ ディレクトリが作られる。中核となるのは次の 3 つだ。

ディレクトリ役割
.trellis/spec/再利用される規約・パターン・ガイド。一度書けば毎セッション自動で文脈注入される
.trellis/tasks/タスクごとの PRD(要件定義)・実装/レビュー用のコンテキスト・進捗ステータス
.trellis/workspace/セッションをまたいで文脈を保つ作業ジャーナル(作業ログ)

ポイントは、これらがリポジトリにコミットされる通常のファイルだということ。チームで共有でき、Git の履歴に残り、レビューもできる。AI の「記憶」を、属人的なチャット履歴ではなくバージョン管理された資産として扱える。

4 フェーズのワークフロー・ループ

Trellis の本体は、タスクを次の 4 フェーズで回すループだ。

Trellis の 4 フェーズ・ループ(Plan・Implement・Verify・Finish)と、その中心にある .trellis ディレクトリが spec・tasks・workspace でプロジェクトの脳として機能し、各フェーズが文脈を読み込み、学びを書き戻す流れを示した図

  1. Plan(計画) — 要件を分析し、prd.md に step-by-step の実装計画を書き出す。trellis-brainstormtrellis-research といったサブエージェントがここで働く。
  2. Implement(実装) — 計画に沿って trellis-implement サブエージェントがコードを書く。注入されたパターンに厳密に従い、この段階では git commit を行わない
  3. Verify(検証)trellis-check サブエージェントが diff をレビューし、lint・型チェック・テストを実行して、コードがプロジェクトの基準を満たすか確認する。
  4. Finish(仕上げ) — 今回の作業で得られた学びを .trellis/spec/ に書き戻す。これにより使うほどプロジェクトの「脳」が賢くなる

このループの肝は最後の Finish にある。実装で見つけた新しい規約や落とし穴を spec に還元するので、次のタスクではその知見が最初から文脈として効く。spec-driven development(仕様駆動開発)の発想を、AI エージェント運用の文脈に落とし込んだ形だ。

導入手順

前提として Node.js ≥ 18.17.0 が必要だ。加えてワークフローを支える .trellis/scripts/ のユーティリティが Python(≥ 3.9)を利用する。

グローバルインストールする。

npm install -g @mindfoldhq/trellis@latest

プロジェクトのルートで初期化する。-u には作業者名を渡す(workspace/ のジャーナルがユーザー単位で分離される)。

trellis init -u your-name

Claude Code 以外のプラットフォームも併用する場合は、対象をフラグで指定して生成できる。

trellis init --cursor --opencode --codex -u your-name

初期化すると .trellis/ と、各プラットフォーム向けの生成ファイル(Claude Code なら .claude/ 配下の skill / agent など)が配置される。あとは普段どおり Claude Code を起動すれば、Trellis が文脈注入とフェーズ管理を引き受ける。

どんな人に向くか

元投稿が挙げている「向いている人」は、そのまま導入判断の目安になる。

逆に、使い捨ての小さなスクリプトを単発で書かせる程度なら、.trellis/ を整える手間のほうが上回るだろう。Trellis が効くのは「同じリポジトリに AI が何度も戻ってくる」状況だ。

まとめ

Claude Code 単体は、優秀だが毎朝記憶を失って出社するプログラマに近い。Trellis は、その記憶を .trellis/ というバージョン管理された「プロジェクトの脳」に外部化し、計画 → 実装 → 検証 → 書き戻しのループで運用を仕組み化する。

「AI が不安定」と感じたとき、モデルを乗り換える前に、まず文脈の供給を仕組みにする——という発想の転換を促してくれるツールだと言える。リポジトリは mindfold-ai/Trellis、ドキュメントは docs.trytrellis.app にある。

本記事は X の投稿(@XAMTO_AI)をきっかけに、Trellis の公式リポジトリ・ドキュメントで内容を確認しながら構成したものです。



前の記事
キーを持たずに AWS へデプロイし、夜間に自動適用する — GitHub Actions 運用設計ノート
次の記事
今週GitHubで急上昇したAIリポジトリ10選