AI駆動開発でMovable Typeプラグインを作る：MT9とAIエージェントの協働
今年もルーティンになりつつある結婚記念日にブログを書くサイクルを実行していきます！（結婚して12年）
今年もMovable TypeのAdvent Calendarに参戦します。参加は9年目、あと1年で10周年を迎えます。
昨年は「静的ファイル出力は永遠に不滅です。これからのMovable Typeの付き合い方」という記事で、Movable Typeやコミュニティとの関わり方について書きました。
今年のGW中には「Devin AIのDeepWikiを使って Movable Typeプラグインを開発してみた」という記事で、DeepWikiを使ったプラグイン開発について書きました。
今回はAIエージェントを駆使して 「AIレビュー」 いうプラグインを作りました。
この記事では、AI駆動開発における人間の役割と、人間が知っておくべき領域について、実際の開発経験を通じてまとめていきます。
実装時間：3時間程度で完成した「AIレビュー」プラグイン
今年は、AIエージェントが目まぐるしい進化を遂げたこともあって、「Movable Typeのプラグインも爆速で作れるのでは？」という発想で作ってみました。
その中で、別の観点でAIを活用する部分は何かということを考えた上で、AIレビューが良いのではないかと思い作ってみました。
記事のチェックはChatGPTを活用することはありますが、コピーペーストだったりフィールドごとにチェックするためのコピペが面倒です。
MTでそのままAIレビュー機能が搭載されていたら、不毛なコピペからの脱却ができるのではないだろうかと感じました。
実装としては、OpenAIやGeminiなどのAPIを提供するインターフェースだけを提供し、コンテンツの品質一次チェックとして使えればユーザーとしては価値があると感じました。あくまでも仮説ではありますが。
入力したコンテンツをフィールドを選択しレビュー
このプラグインではレビュー対象となるフィールドを指定できるという部分を対象範囲を決めてレビューすることができるようにしました。
AIのプロンプトの指示の入力欄には、どのような観点でレビューをしてもらえるかなど入力できます。
また、よく使うプロンプトも設定画面から定義することができます。
フィールドの情報テキストを元にAIにわたすプロンプト指示の情報として受け渡し、レビューを実施してくれます。
登録方法
まずは、Google AI Studio でGemini API Keyを取得します。
今回はお試しで作ったので、Geminiを採用しました。
取得したAPI Keyをプラグインのシステム設定から登録を行います。
また、レビュー時のカスタムプロンプトもシステム設定から行えます。
以前の記事で、AIレポートという機能を作ってみました。
今回のプラグインでは内容は違うもののAIに受け渡すというフローを別の視点で実装・プラグイン化にしました。
AI活用でMovable Typeの見えない部分（機能や実装など）を可視化できるようになった
今回、AIをフル活用してバイブコーディング・AI駆動開発を行った中で、感じた点は よりMovable Typeの内部構造を知識として得ることができたことです。
AIレビューのプラグイン自体は、MT9の内部を知るための一つの手段でした。
実装過程で、Movable Typeがどのように進化していたのか。この1年ぜんぜん触らなかったからこそ学びがありました。
SaaS系になってしまうと内部構造は知る手段がなかなかありません。
そういう意味でまだまだソフトウェアに魅力を感じています。
もっとこうしたいというカスタマイズを求めるのは玄人向けではありますが、AIを活用していく過程でMTを深く学べるチャンスだと私は感じました。
MTを知らない新人さんやこれからMTを触る人には、一度ソフトウェアの内部構造をAIで調査したり企業向けの学習方法として採用するのもありではないでしょうか。
これまでの開発では、コアのソースコードを実際に読んでみて、どこでカスタマイズするのか、ドキュメントを一から読んでいく必要がありました。
その読んでいく工程も楽しい部分ではあるものの、実現可能性の判断を即座にするためにはAIをフル活用していくのは一つの手段だと感じています。
DevinのDeepWikiが無料でOSSであるため、ドキュメントを生成してもらえるようになり、そのハードルは一気に下がりました。
Ask Devinを使えば、ソースコードを調べることももちろん、ユーザー目線でいえば使い方についてもAIに回答してもらえるようになりました。例えば、コミュニティで質問を投げるよりAIに回答してもらえるという武器を得た感覚を持っています。「MTMLでこういうテンプレートを作るには？」「MTMLの条件分岐の条件を教えて」「この機能はどこにありますか？」など、AIチャットボットでソースコードや機能についての質問も容易になりました。
DeepWikiによるドキュメント生成
今年のGW中に、Devin AIのDeepWikiを活用してMovable Typeのドキュメントを自動生成し、Deep Researchを使ってプラグイン開発を行いました。
- DeepWikiでGitHubリポジトリから自動的にドキュメントを生成
- Deep Researchでプラグインの作り方を自然言語で質問
- 生成されたコードを手元で動作確認し、エラーを修正
この方法で、mt-plugin-CalendarPeriodField（カレンダー期間フィールドのプラグイン）を1時間程度で作成できました。
当時は、Devinに課金をしておらず、DeepWikiだけを活用して自分で実装を行いました。GW時点では、AIエージェントが次々と登場し、AIエージェントの波が一気に押し寄せてきた感覚でした。DeepWiki以降は、Devinの利用検証やCursorといった他のツールを使った検証を行っていました。
8ヶ月が経過し、状況が大きく変化した中で、再度AIエージェントを駆使してMTプラグインを作ることに挑戦し、その過程を記事にまとめました。
MT本体ソースをコンテキストとして活用
今回のAdvent Calendarでは、より直接的なアプローチを取りました。
AIエージェントでプラグインを実装する際のコツは、MT本体のコアソースを先にコンテキストとして読み込ませておくことです。
Movable TypeのGitHubリポジトリのソースコードを事前に開発環境に用意しておくと、AIエージェントがコードの文脈を理解し、プラグイン設計の一次情報として活用できます。
有効理由
- 一次情報の提供: 実装する環境のディレクトリ内にソースコードがあることで、MT本体の内部での動きやコードの意図を把握して進めることが可能になる
- コードの意図の理解: ドキュメント化されていない内部実装の詳細を、AIが直接コードから読み取れる
- 最新の実装パターンの把握: MT9の新機能や変更点を、ソースコードから直接理解できる
仕事の都合も大きいですが、私の実装環境ではCursorを利用しました。MT9のコアは以下のように配置しました。
AI駆動開発における人間の役割
AIレビュープラグインを作りたかったわけではなく、AI駆動開発によって顧客の要望により早く仮説検証できることを伝えたかったのです。
AI駆動開発（AI-driven Development）とは
ただし、これは単なる開発手法の話ではありません。現場目線で見れば、ソフトウェアを作るプロセスそのものが「個人」「チーム」「組織」という3つのレイヤーに跨っており、知の循環を形成する開発文化そのものだと捉えています。
アジャイル開発が「人とプロセスの関係性」を再定義されたように、AI駆動開発は「人と知の関係性」を定義しているように感じています。
AI駆動開発を実際にプロダクト開発の中で利用して感じた部分です。
知の循環プロセス
以下の図は、AI駆動開発における知の循環プロセスを示しています。データ収集から始まり、AI解析、知識提示、人間の判断、フィードバックというサイクルが、個人・チーム・組織の各レイヤーで回り続けます。
各レイヤーの役割と成長の方向性
各レイヤーにはそれぞれ異なる役割があり、それぞれの成長の方向性があります。
| レイヤー | 役割 | 成長の方向性 |
|---|---|---|
| 個人 | AIと対話しながら思考を深める | 知の外化と再構成 |
| チーム | 知識を共有し合い意思決定を支援 | コラボレーションの強化 |
| 組織 | 知識を体系化し再利用 | 学習する組織への進化 |
顧客との対話から潜在課題を見つけていく
これまで、クライアントの意見を聞いて持ち帰り、その課題を1人やチームで検討してから提案していました。
しかし、AIエージェントで仮説検証自体が容易になったことから、クライアントとのミーティング中でもAIを駆使してその場で提案できるようになりました。
コンテンツを作成する業務そのものが無くなりつつありますが、クライアントの課題は変化し、違う部分で受託業務は発生します。
AI駆動開発は、リアルな対話からその場でAIを駆使して開発することだと私は思っています。
アイディアベースから開発の手法に多岐にわたってAIを活用することで、時間を短縮できているのではないでしょうか。
人間の役割は、顧客の声に沿って顧客とともに構築することがより早くなったのではないでしょうか。精度はどんどん上がっていきますが、意思決定の速度も上がっている印象があります。
より思考を駆使しなければならない業務に専念していくことになると感じています。
1. アーキテクチャの理解
AIエージェントが効果的に動作するためには、人間がシステムのアーキテクチャを理解している必要があります。
- MT本体の構造を把握している: プラグインがどのようにMT本体と連携するか
- プラグイン開発のパターンを知っている: 既存のプラグインの実装パターンを理解している
- ドメイン知識: Movable Typeの仕様、コンテンツモデル、APIの使い方
MTにしても他のスクラッチや基幹系システムでも、アーキテクチャの理解は人間が必ず理解しておく必要があります。残念ながら、現時点でAIがあなたのプロダクトコードをすべて自動化で管理することはできません。
2. コンテキストの提供方法
AIエージェントに適切なコンテキストを提供することが重要です。
適切にプロダクトのコードを解釈させて育てなければなりません。どのような背景でどう処理させるのか、どんなルールにするのかは、先に指示しなければなりません。
プラグイン開発において、どのような課題があって解決方法を提案するための情報を与えた形で進めなければ、余計な遠回りをします。何度もプロンプトを駆使して無駄にAIと会話する時間すらも、AI駆動開発するためには削減する必要があります。コンテキストを適切に与えておくことがおすすめです。
- 何を伝えるか: 作りたい機能の要件、制約条件、既存の実装パターン
- どうやって伝えるか: プロンプトの設計、コンテキストファイルの配置、AGENTS.mdの活用
- 一次情報の提供: MT本体のソースコードをディレクトリ内に配置し、AIが直接参照できるようにする
3. 実装の検証と調整
AIの出力をどう評価・修正するかが、開発の成否を分けます。AIが出力したコードをそのまま提供することは、責任が取れません。
誰がどんな立場でも、必ずエンジニアの目線でのレビューは実施するべきです。非機能要件やセキュリティの観点など、いままでのルールがなくなったわけではなく、いままでのルールの上でレビューや品質のチェックは必要です。
また、同じエラーで失敗したなと繰り返すよりも、なぜ同じところで失敗するのかという部分を深堀りして解消させることで、躓くポイントを先回りして提供できるコンテキスト（ドキュメント）にしておくと、スムーズに開発ができるようになります。
- 動作確認: 生成されたコードが実際に動作するか確認
- エラーの分析: エラーメッセージから問題を特定し、AIに適切な修正を依頼
- 品質の担保: コードの品質、セキュリティ、パフォーマンスを人間が最終的に判断
4. ドメイン知識の重要性
AIは汎用的な知識は豊富ですが、特定のドメイン（Movable Type）の知識は限定的です。Movable Type固有の知識をAIに学習させておくことをおすすめします。
同じChatGPTでも与えた情報によっては、返ってくる解答は異なります。AIエージェントでも同じことが言えます。コード内にMTに関する適切な情報があることが必要になります。
ユビキタス言語など特定の名前などを把握しておくと、プラグインの実装コード自体の品質を高めます。
- Movable Typeの仕様: プラグインの登録方法、フックポイント、APIの使い方
- プラグイン開発のパターン: 既存プラグインの実装パターン、ベストプラクティス
- MT9の新機能: 新しく追加された機能や変更点を理解している
MT9について
今回の記事には触れませんでしたが、久しぶりにMTを触ってMT9を触ってみて、色々変わっていて迷子になりました（笑）。
玄人時代だったときは、常に見ていたからどんな機能が出たのかとかはすぐに検証していましたが、これだけ本業とかけ離れてしまったこともあり、MT初心者になったのを強く感じました（笑）
AIにあらかじめMT9のコードを学習させておいたことも大きかったです。
1時間くらいの学習・会話で、無事に舞い戻ることができたのは大きかったです。
AIレビュープラグインの実装過程・実装フロー
実際にプラグインを作るまでの工程は以下の流れでした。
バイブコーディングのような形ではありましたが、最初にプランを設定させたことで早く要件定義や設計が行えました。
- MT9の学習: まずは、AIにMT9について学習させた
- 要件定義: AIを使って記事をレビューする機能を実装したい
- コンテキストの準備: MT本体のソースコードを開発環境に配置
- AIエージェントとの協働: プロンプトで要件を伝え、コード生成を依頼
- 動作確認と修正: 生成されたコードを動作確認し、エラーがあれば修正を依頼
- 完成: 動作するプラグインが完成
まとめ
今回、AIレビュープラグインを3時間程度で作ることができました。
GW中にDeepWikiで作ったときも1時間程度でしたが、今回はMT本体のソースコードを直接コンテキストとして活用したことで、よりスムーズに開発できたと感じています。
AIエージェントと上手に付き合うことで、アイディアの実現可能性を即座に検証できるようになりました。
以前は数日かかっていたプラグイン開発が、数時間で完了できるようになったのは、本当に大きな変化だと思います。
ただ、AIに任せれば何でもできるわけではありません。
MT本体がどう動いているのか、プラグインがどう連携するのかを理解していないとAIに適切な指示を出せません。
バイブコーディングで与えるコンテキストも意識する必要があります。
AIに何をどう伝えるかで、生成されるコードの質が大きく変わります。MT本体のソースコードを開発環境に配置しておくだけで、AIの理解が深まるのは実感しました。
AIが生成したコードをそのまま使うのではなく、必ず動作確認をして、エラーがあれば修正を依頼する。この繰り返しが重要です。
Movable Typeの仕様やプラグイン開発のパターンを理解していることで、AIとの対話がスムーズになります。
AIは強力なツールですが、それを効果的に活用するためには、人間の知識と経験が不可欠です。
説明責任、知識と経験を学び続けること、最後にコードの妥当性の責任。これらは、AIエージェントが進化する中でも、変わらない部分だと現時点では感じています。
今回の記事では、MTプラグインを題材にAI駆動開発における人間の役割についてまとめてみました。
MTプラグインに限らず、AIの活用ポイントやMTプラグインを作ってみたい方は、ぜひAIエージェントを活用してみてください。
Discussion