CodexからContentfulへ直接下書き保存する方法

Composio MCPでブラウザ依存を減らす運用手順

Contentful を使って記事を運用していると、下書きのたびに管理画面を開いて、ログインして、記事を作って、保存して、確認して、という流れが発生します。件数が少ないうちは問題ありませんが、AI で記事の下書きを作る運用に移ると、この最後の保存作業だけが手作業のまま残りやすくなります。

そこで今回は、Codex から Contentful に直接アクセスし、ブラウザを使わずに記事の下書き保存や Content Type の確認を進められるようにした方法を整理します。実際には Composio の MCP 連携を使い、Codex と Contentful を接続する構成です。

結論

結論からいうと、通常の下書き保存、記事一覧取得、Content Type 確認までは、Codex から直接進められるようになります。ブラウザ操作が必要なのは、原則として初回の OAuth 承認、または将来の再認証時だけです。

日常運用では、記事の本文作成から Contentful への下書き保存、Entry ID の確認までを、チャット内の流れで完結しやすくなります。

全体の流れ

今回の構成は、ざっくりいうと次の流れです。

1. Codex に Composio の MCP 接続を追加する

2. Composio 側で Contentful 連携を有効化する

3. 初回だけ Contentful 側で OAuth 承認を行う

4. Codex から Contentful の Space、Environment、Locale、Content Type を確認する

5. 記事を draft として保存し、保存結果を読み返して検証する

この方法のメリット

この方式の利点は、単に「記事を投稿できる」ことだけではありません。

まず、Space ID や Environment ID、Locale、Content Type、必要フィールドを一度確認しておけば、次回以降はその情報を再利用できます。毎回「どの Content Type だったか」「記事保存に必要なフィールドは何か」を探し直さなくて済みます。

さらに、保存後に Entry ID、slug、更新時刻まで読み返して確認できるので、「保存したつもり」で終わらず、実際の保存結果を記録に残しやすい点も実務向きです。

最初に理解しておきたい注意点

一方で、最初に理解しておいたほうがよい注意点もあります。

まず、Contentful への公開まで自動化できるとしても、公開操作は別扱いにしたほうが安全です。下書き保存は自動化し、公開だけは人間承認を残す、という運用のほうが事故を減らせます。

また、Contentful には Content Delivery API と Content Management API の違いがあるため、「読めること」と「書けること」は分けて考えたほうがよいです。記事の下書き作成まで進めたい場合は、管理側の書き込み権限を前提にした接続確認が必要になります。

初回セットアップでやったこと

実際の初回セットアップでは、まず Codex 側で Composio の MCP 設定を行いました。次に Composio プロジェクト API キーを設定し、Codex から Composio MCP にログインできる状態を作りました。

そのうえで Composio の contentful ツールキットに対して接続を開始し、Contentful 側の承認画面で Authorize を実行しました。この最後の承認だけは、本人操作が必要です。ここが終われば、以後の通常作業ではブラウザ依存をかなり減らせます。

## 接続後に先に確認しておくべきこと

接続後は、いきなり記事保存に進むのではなく、先に Space 一覧、Environment 一覧、Locale 一覧、Content Type 一覧を確認しておくのがおすすめです。

これにより、次の点を正確に把握できます。

- どの Space に書くのか

- 本番 Environment は何か

- 既定 locale は何か

- ブログ記事は blogPost なのか別名なのか

この確認を最初に挟むだけで、後の保存エラーやフィールド不一致を大きく減らせます。

## 記事保存時に揃えておきたい項目

記事を保存する際は、最低限でもタイトル、slug、公開日、本文を揃えておくと扱いやすくなります。さらに、カテゴリ、抜粋、meta description、必要に応じてアイキャッチ画像の Asset Link まで用意しておくと、管理画面側での追加入力を減らせます。

本文はプレーンテキストのままではなく、Contentful の Rich Text 構造に合わせて保存する必要があるため、見出しや箇条書きを含めて整形ルールを決めておくと、再利用しやすくなります。

保存後に必ずやるべき確認

保存後に重要なのは、必ず読み返し確認を行うことです。

- 最新記事一覧から新規 Entry が見えるか

- Entry ID は何か

- slug は意図通りか

- 更新時刻は直近になっているか

この確認まで含めて初めて「保存できた」と扱うほうが、実運用では安定します。

記事制作フローに組み込む場合も、次のような形にしておくと役割分担が明確になります。

1. 本文生成

2. 下書き保存

3. Entry ID 記録

4. 人間確認

5. 公開

この方法が向いているケース

この方法が向いているのは、Contentful を CMS として使っていて、AI で記事制作を進めたいチームです。特に、下書き作成の件数が増えてきたとき、あるいは複数サイトで同じような運用を広げたいときに効果が出やすいです。

毎回ブラウザで保存する作業を減らせるだけでなく、「保存確認まで含めた標準フロー」を作れるので、属人的な運用から抜けやすくなります。

導入するならどう進めるべきか

もしこれから導入するなら、おすすめの考え方はシンプルです。

最初の 1 回だけ、Composio と Contentful の接続、Space / Environment / Locale / Content Type の確認、そしてテスト用の 1 記事保存までを通してください。そこで使った ID や手順をドキュメント化しておけば、次回からはその確認を繰り返す必要がなくなります。

結果として、Codex を「文章を書く AI」ではなく、「下書き保存まで進める運用担当」として使いやすくなります。

まとめ

今後、Contentful を使ったコンテンツ運用で、記事制作の最後だけ人手に残っているなら、一度この構成を試してみる価値はあります。

初回承認さえ終われば、日常の下書き保存はかなりスムーズになりますし、複数案件へ横展開する際にも再利用しやすい方法です。