普段はビジネス側の上流工程にいます。
エンジニアの現場を離れて、数年になります。
構想を作って、戦略に落として、必要なら自分で手を動かす、という動き方をしています。
もともとはフロントエンドエンジニアでした。
といっても開発の最前線というより、運用やデザイン寄りです。
転職サービスのサイト運用や、ECサイトの制作支援をやっていました。
ただ、ここ数年は事業側にいて、コードから離れていました。
そして正直に書くと、バックエンドもインフラもセキュリティも、実務では触ったことがありませんでした。
その状態で、個人でやっているサイトを一から作り直しました。
2026年8月23日に本番へ切り替えて、いま動いています。
何ができたのか
「イヌコミ」という、犬と一緒に入れるお店を紹介するサイトです。
2024年に立ち上げて、WordPressの有料テーマで作ったものでした。
それを、Next.js・Supabase・Vercelを軸にしたスタックで作り直しました。
テーマの差し替えではなく、データベースの設計からです。
できあがったものを、正直に並べます。
訪れる人が使うのは、店舗の検索・一覧・詳細、エリア別ページ、ランキング、クチコミ、
ニュース、イベント、犬のクイズ、AIに相談できるチャット、ブックマーク、ポイント、日英の切り替え。
それと、愛犬の記録機能。登録、体重、ワクチン証明書などの記録、食事、支出。
食事は写真を撮るとAIがカロリーを見積もります。
お店の人には、招待制のポータルがあります。自分の店の情報を自分で直せます。
開発者向けには、APIのドキュメントとダッシュボード、キーの発行、利用量の計測。
犬種ごとの統計は、個別の犬が特定されないよう、10件以上集まったものだけを返すようにしてあります。
AIエージェントが直接読める窓口も用意して、データを「参照される資産」にする側の設計も入れています。
そして運営のための管理画面も、全部自分用に作りました。
記事・ページの編集、メディアライブラリ、店舗、クチコミ審査、広告枠、ポイント、
問い合わせの設計と返信、権限ロール、監査ログ、翻訳管理。
いちばん作り込んだのは、AIのコストや死活、ログインの異常に人が見ていなくても気づける側です。
一人でやっている以上、見張りは機械に任せるしかないので。
裏側は、データベースの機能テーブルが106本。
サーバー側で動く処理が418個。AI関連のコードが18ファイル・4,174行。
本業の傍ら、平日の夜と週末だけ。期間は約9か月で、手を動かした人間は私1人です。
※実際のリリューアル時までのトータル稼働工数でいうと約2〜3人月ほどです
ただ、断っておくと、この約9か月は開発だけの期間ではありません。
いちばん手間がかかったのは旧サイトからの店舗記事の移行で、
いま本番に並ぶ256件の大半をひとつずつ運びました。しかもその間も新しい記事は増え続けていました。運営は止められないので。
完全な新規開発だったら、ここまではかかっていないと思います。
知らない領域に、どう踏み込んだか
WordPressのテーマで作ったサイトには、限界がありました。
やりたいことが増えるたびに、テーマの想定の外へ出ていく。
作り直すしかない、と思いました。
ただ、作り直すのに必要な知識が、私にはありませんでした。
最初から作戦があったわけではありません。
とりあえず手を動かして、そして早々に行き詰まりました。
同じところで何度も崩れる。直したはずのものが、また戻る。
知識がないので、崩れていること自体に気づけない。
「これは、自分の注意力でどうにかする話じゃないな」と思いました。
作り始めてすぐに、守るべきことを文章に書き始めました。
何を絶対に壊してはいけないか。どこで自分に確認を取らせるか。
自分の判断力を信用しなかった、と言ってもいいと思います。
そこからは試行錯誤です。
名前は2回変わりました。置き場所も変わりました。ルールは75ファイルまで増え、
構造を組み直して、2026年4月10日に「Axiarch」という名前でオープンソースにしました。
理屈が先にあったわけではありません。
このサイトを作りながら、必要に迫られて生まれたものです。
公開して終わりでもなく、本番に出すまで使いながら直し続けて、
いまの形になりました。
扱っているものが軽くありません。
ワクチン証明書などの記録、体重、支出、問い合わせの本文、決済。
権限の設計を間違えても、画面は普通に動きます。
経験のない私が、目で見て気づけるわけがない。
だったら、気づけなくても壊れない形にするしかありませんでした。
具体的には、3つだけです。
- 守るべき線を、コードより先に決める
- 線が動いたら、機械が赤くする（赤＝検査が失敗して止まる状態）
- 取り返しのつかない操作は、必ず自分の承認で止める
結果として、データベースの表は120あります（機能テーブル106本＋作業用の表14本）。RLS（行ごとに誰が見てよいかを決める仕組み）を入れていない表は、0でした。
これは私が優秀だからではなく、1つでも抜けたら機械が赤くするようにしてあるからです。
やってみて分かったこと
技術的な学びもたくさんありましたが、人の話として残ったのは2つです。
ひとつは、「知らない」は、進まない理由にはならなかったということです。
知らないことを埋めようとすると、勉強が終わるまで動けません。
でも「知らないまま進んでも、品質が底上げされる仕組み」を作ることはできました。
実際、私はいまも自分でRLSのポリシーを一から書ける自信はありません。
それでも、間違っていたら赤くなる状態は作れました。
もうひとつは、自分の検査を疑うのが一番難しかったということです。
守りが効いているか確かめるために、守りをわざと壊してテストが赤くなるか見る、
という検査をしていました。壊したのに、緑（＝合格の表示）のままでした。
壊す処理が、狙った場所ではなく別の場所に当たっていたからです。
「壊したこと」は確認していて、「狙ったところを壊したこと」は確認していなかった。
うまくいっていない可能性より、うまくいっていると誤解している可能性のほうが怖い。
これは開発に限った話ではないな、と思っています。
これから一緒にやりたいこと
私は「作れる戦略家」でありたいと思っています。
構想を語るだけでも、実装するだけでもなく、
その間の翻訳を引き受けられる人でいたい、というのが軸です。
いま関心があるのは、AIを前提にした開発や業務の組み立て方です。
ツールを導入する話ではなく、任せる範囲と、任せない範囲をどう線引きするかのほうです。
やってみて分かったのは、事故は「AIが間違えたとき」ではなく
「誰も見ていない境界」で起きるということでした。
そこを設計できる人は、まだ少ない。
そして、事業側の人間がここを分かっていると強い、とも思っています。
「技術が分かる人しかできない」という前提を、私はあまり信じていません。
必要なのは知識ではなく、知らないまま進んでも、品質が底上げされる順番（仕組み）のほうでした。
こういうご相談なら、力になれると思います。
- AIを使った開発の立ち上げ方と、品質をどう担保するか
- 内製化の線引き（どこまで任せ、どこを人間に残すか）
- 自社データをAIから参照される資産に変える設計（RAG＝AIに自社の知識を参照させる仕組み・ナレッジ資産化）
- 開発ガバナンスの設計、技術顧問、スポットでの現状診断
- 事業と技術のあいだの翻訳が必要な、新規事業の立ち上げ
なお、私が引き受けるのはコードの逐行レビューではなく、全体設計と仕組みのほうのレビューです。
コードの正しさは、機械の検査に判定させます。
形式は、1回だけのスポット相談から、月次の顧問、数か月の伴走まで。
最初は「いま何に困っているか」を教えていただくだけで十分です。
まだ固まっていない段階のほうが、直せることが多いと感じています。
あとは個人的な話ですが、ペットや動物の領域にはずっと関心があります。
今回のサイトもその延長でやっています。
この領域でご一緒できる方がいたら、うれしいです。
リンク
- Axiarch（OSS / Apache 2.0）: https://github.com/hiroyuki-miyauchi/axiarch
- 運営メディア Chronoviq: https://chronoviq.com/
- ご相談の窓口: https://chronoviq.com/contact/
- お急ぎなら、Wantedlyのメッセージでもどうぞ
