2025年12月10日
この記事は Hono - Qiita Advent Calendar 2025 - Qiita の12月10日の記事です。
今年の10月から主にHonoXで作った飯ログという飯屋の訪問履歴を公開するサイトを運営している。
https://github.com/qlitre/meshi-log
ユーザーに使ってもらうタイプのサービスではなく、自分が訪問した飯屋の記録をひたすら公開しているサイトだ。HonoXとデータはmicroCMSに登録して動かしている。
10月に立ち上げて約2ヶ月のあいだ運営をしてきた。気分を乗せるために独自ドメインもとったりした。その過程でデータも増えてきた。併せて機能追加も進めてきた。
今日はその中で感じたことや追加機能について書いていきたい。
改めてHonoとmicroCMSの組み合わせは小規模なサイト公開ではかなりよい構成かと思った。
以下に理由を書く。
honoでエッジにデプロイしてmicroCMSにAPIリクエストを送れば、すぐに登録したデータを世界に公開できる。この気軽さとスピーディ感が自分のニーズに合っていた。今回の飯ログについても、あまり凝ったことは考えずにとにかく飯屋の訪問記録を残したいという気持ちだけが最初にあった。Next.jsやNuxt.jsでサイト公開をしたこともあるが比較するとhonoが一番気軽に公開できたと感じた。シンプルに書けることだったり、立ち上がりの速さだったりデプロイの速さのもろもろのDXがいいことが要因だと思う。この「気持ちが軽い」というのが自分にとって大事な基準だ。仕事ではなく趣味で公開しているサイトなので、あまり重いことは考えずに、軽やかな気持ちでコードとは向き合いたい。
CloudflareにもD1、R2というデータを貯める仕組みはある。しかし、今回の飯ログのように写真付きで文章を書く場合、どうしてもリッチエディタが欲しくなる。ここを個人で自作するのはかなり難しい。登録画面を認証付きで実装するのにも工数がかかる。もろもろをすっとばして無料プランでリッチなエディタが使える。これはmicroCMSを採用した強力な動機だった。
そしてhonoといえばhono/mcp。これからhono x Cloudflareで開発をする場合にmcpを生やさないという選択肢はありえないのでは、そのくらい面白いし強力なツールだと思っている。
今回は初めての試みとして開発連携を試してみた。
ちょうど9月末頃にmicroCMSでAPIスキーマ取得APIのリリースがあった。
これを早速honoのmcpサーバーを組み合わせてみる。具体的にはプロジェクトの中に/mcpルートを生やして、microCMSのAPIスキーマを返すツールを設定した。
export const getMcpServer = async (c: Context<Env>) => {
const serviceDomain = c.env.SERVICE_DOMAIN
const apiKey = c.env.API_KEY
const client = getMicroCMSClient(c)
const server = new McpServer({
name: 'meshi-log MCP Server',
version: '0.0.1',
})
server.registerTool(
'get_api_schema',
{ title: 'Get Api Schema', description: 'get microcms api schema', inputSchema: {} },
async () => {
const result = await getMicroCMSSchema({
serviceDomain: serviceDomain,
apiKey: apiKey,
})
return {
content: [
{
type: 'text',
text: JSON.stringify(result, null, 2),
},
],
}
}
)
}こんなコードをデプロイして、あとは開発で用いているClaude Codeに参照MCPサーバーとしてつなげる。
そうすると例えばAPI定義に変更があった際にClaude Codeにこう指示するだけでよい。
「shop APIに最寄駅の項目を追加しました。飯ログのMCPツールを使ってタイプ定義、情報表示の修正をしてください」
小規模なプロジェクトでも、APIスキーマを変更するとそれなりに修正工数がかかる。
type定義の変更、fetch処理の修正、表示変更など。
このあたりを正しいAPI変更情報に基づいて修正を走らせてくれる。とても体験が良い。
Cloudflare Workersで動いてるmeshi-logにmicroCMSのAPIスキーマ情報を取得できるMCPをのせて、Claude CodeでMCP接続設定して、API設定変更あった時にmeshi-logの開発時によしなに修正かけてくれるようになった。かなり体験いい。 pic.twitter.com/BmxGQtopdk
— qlitre(くりったー) (@kuri_tter) October 4, 2025
データを登録していく過程でいろいろな機能を追加した。
前述のAPI取得の他に、お店検索、ジャンル検索、地区検索、訪問記事確認のツールを配信している。
例えば新宿のおすすめのお店をきいてみる。そうするとAIがまずareaを検索して新宿区のIDを取得して、それをもとにフィルタリングして表示、ということをやってくれる。

ツールをいろいろ持たせることでよしなに情報を整理してくれる。これが面白い。
自分は新宿で乗り換えているため新宿の飯屋に行くことが多い。これからも攻めたい。
MCPは以下のURLにお手元のクライアントから接続すればすぐにアクセスできます。
RSSフィードでも受け取れるようにしている。
https://meshi-log.info/feed.atom
URLクエリパラメーターで制御している。こちらでもおすすめのお店がすぐに探せる。

マップで訪問した店が見れる。このページは全てClaude Codeに書いてもらったが、Openstreat MAPで実装している。
今のところ特段何かの役に立っているということはないが、ピンが増えるとなんかうれしい。
それだけでページ作った価値があった。

ここは下北沢の至高の角打ち屋、落合酒店。ライブ前によくいく。
サイトの紹介ページ。ここだけMDXでレンダリングしている。ルートごとにレンダリング方式を変えてMDXでページを作れるというHonoXの思想がとてもいい。
10月の稼働開始から本記事の公開まで48件のお店、66件の訪問記事を作成した。
2ヶ月の間、飯を食っては記録をしてきた。そうして欲しくなった機能を追加するという営みを行ってきた。機能を追加するとまた新しい飯を食いたくなって・・・そういう好循環が生まれている。率直に自分の行動でデータが溜まっていくのが楽しい。飯屋に行くというのがモチベーションというか、ドリブンになっていて、これはまさに飯駆動開発とでもいうべきか、そんな言葉が頭の中にこびりついている。
新しいお店に行った時の登録がすこし面倒だ。新規店舗食べログを参考に住所を調べて、地区コードを調べて追加、ジャンルを追加、緯度経度をgeocodingなどで調べて入力をすることもある。意外と手数が多い。平常時なら全く問題がないが、このサービスの都合上、酒を飲んだあとの操作も意外と多い。酔った頭でこの処理するのはしんどい。
ここで、お店の登録に関してはAIに任せてもいいと思っている。例えばMCPに登録ツールを持たせて「このお店に行ったのでデータ登録して」みたいな感じでClaudeアプリから指示ができたらめちゃくちゃ楽だ。データ登録MCPとなると認証の問題があるが、そこも最近のリリースで使いやすくなったというような情報が出ていた。
(まだ試していない、本当はここまで試して投稿したかったが時間がとれず…)
コーディングはずいぶんAIに助けてもらっている。すごい時代になったもので、ぶっちゃけてしまうとフロントエンドサイドはClaude Codeに任せてほとんど自分でコーディングをしていない。しかしながら、飯を食うことはAIにはできず、ここは自分でやるしかない。この「AIは飯を食えない」ということを最近よく考えている。人間の仕事の行き着く先は飯を食ったり酒を飲んだりすることなのかもしれない。会食で仕事をつないだりすることがこれまで以上に重要になるのかもしれない。
今年もアドベントカレンダーに参加することができてよかったです。なんとなく自分の中で節目になっているような気がして年の瀬を感じています。忙しい日々が続くかと思いますがくれぐれも体調には気をつけて過ごしましょう。最後まで読んでいただいてありがとうございます。ではでは。