気づけばDevinのナレッジが山積みに。Terraformで片づけてみた

はじめに

タイミーでPlatform Engineerをしている徳富(@yannKazu1)です。

2025年2月、私たちの開発組織にAIエージェント「Devin」が導入されました。

Devinは、機能開発のサポートやテストケースの提案など、日々の開発に自然と溶け込む形で活躍してくれていて、今では月に数十〜数百件のマージに関わる頼もしい存在になっています（2025年4月17日時点で489件マージ！）。

そんなDevinと一緒に開発を進めるなかで、ある悩みが浮かび上がってきました。それが「ナレッジの管理が難しくなってきた」ということです。

ナレッジが増えてうれしい、でも……

Devinには「ナレッジ」と呼ばれる、ルールや指針のような情報を登録する機能があります。「こういうときはこう書く」「こう判断する」など、チームの経験や判断基準をDevinに覚えてもらうことで、より実用的な回答を得ることができます。

ですが、チーム内のいろんなメンバーがナレッジを追加するようになると、次第にこんな状況が生まれてきました：

どのナレッジが誰の意図で変更されたのかわからない
重複したり矛盾した内容が出てきてしまう
Devinの提案にブレが出るようになった

このままだと、Devinの力を活かしきれない。そう感じた私たちは「ナレッジにもレビューと履歴の管理が必要だ」と考えるようになりました。

Terraformで「Knowledge as Code」を実現してみる

インフラをコードで管理する「Infrastructure as Code（IaC）」のように、ナレッジもコードで管理できたらどうだろう？

そうしてたどり着いたのが、「Knowledge as Code」というアプローチでした。

Terraformを使えば、ナレッジの追加・変更・削除をコードとして記述でき、次のような良いことがあります：

Gitで履歴が追える：誰がどんな意図で変更したかを残せる
Pull Requestでレビューできる：ナレッジにブレが出るのを防げる
terraform planで差分が見える：意図しない変更に気づける
他のAIエージェントに移行しても再利用しやすい

「これならナレッジの質も保てるし、チーム全体での共有もしやすくなるはず」——そんな期待を込めて、Terraformによる管理に挑戦することにしました。

でも、Terraform Providerがない……！

とはいえ、Terraformで管理するには専用のProviderが必要です。調べてみたところ、Devin用のTerraform Providerは世の中に存在していませんでした。

そこで、私は思いました。「それなら、作ってみよう」

Devin Terraform Provider を作ってみた

自作したTerraform Providerでは、以下のような操作が可能です：

👉 Devin Terraform Provider — Terraform Registry

Devinへのナレッジの作成・更新・削除（devin_knowledgeリソース）
フォルダー一覧の取得（data "devin_folders"）
既存ナレッジの参照（data "devin_knowledge"）

ナレッジの作成

resource "devin_knowledge" "example" {
  name                = "Example Knowledge"
  body                = "This is an example knowledge resource."
  trigger_description = "Use this knowledge when talking about examples."
  parent_folder_id    = "optional-folder-id"
}

フォルダー一覧の取得

data "devin_folders" "example" {
  name = "example"
}

ナレッジの参照

data "devin_knowledge" "existing" {
  name = "Example Knowledge"
}

これにより、ナレッジの変更内容をコードで管理しつつ、レビューを通して安心して運用できるようになりました。

これからのこと

Terraformでのナレッジ管理は、私たちにとってとても大きな一歩でした。でも、それは「Devinの管理がしやすくなった」だけの話ではありません。

私たちは今、AIエージェントが自然とチームにいる時代に生きています。そのなかで、単なる効率化ではなく「人とAIが一緒に考え、一緒に働く」開発のあり方をどう作っていくかが重要だと感じています。

タイミーでは日頃から、Notion上にユビキタス言語やチームごとのナレッジが丁寧にまとめられており、ドキュメンテーションの文化が根付いています。こうした文化があるからこそ、今回のような取り組みも自然な流れとして始められましたし、ナレッジを「コードとして残す」ことにもチーム全体で前向きに取り組むことができました。

これからの開発の現場では、Devinだけでなく、Jules、Cursor、Copilotといった様々なツールが活躍するようになるかもしれません。そうした多様なAIと気持ちよく協力していくために、私たちは次のような基盤づくりを進めていきたいと思っています：

Devin以外のAIでも参照できる、再利用しやすいドキュメントとその自動更新の仕組みを整える
- ナレッジを「読み物」ではなく「役立つデータ」として整理し、どのエージェントでも活用できるようにする
「Knowledge as Code」から「Project as Code」へと視野を広げる
- スプリントの運用方法、CI/CDの流れ、ドキュメントの構成や技術方針までをコードで一元管理し
- AIがそれらを理解した上で、プロジェクトの流れに沿った提案をしてくれるような世界へ
全社的にナレッジを育てていける運用の仕組みを整える
- 各チームがそれぞれルールを持つのではなく、共通のガイドラインと形式で蓄積・再利用できるようにし
- 自動化と人のレビューをうまく組み合わせて、スピード感と品質の両立を目指す