TOPICSInterview１日で、会社の顔を変える。代表が実践した、AIファーストのWeb制作。

最初に整理したのは、事業の情報と、届けたい相手です。自治体や中小企業には、デジタルの相談相手が身近にいない、改善したい業務を実装へつなぐ人が足りない、という課題があります。私や弊社のITの知見を、そこへ届けたい。ホームページのリニューアルは、その入口をつくる仕事でした。

学校に通うことが難しい子どもたちにも、学びと出会う機会があってほしいんです。自分でつくり、誰かに見てもらい、「自分にもできる」と感じる。開発の現場で得た知識を、そういう経験にもつなげたい。企業への技術支援と、人材育成の話は、私の中では一本につながっています。

これを画面に落とすには、訪問者の疑問を順番に解く必要があります。「何をしてくれる会社か」「自分の課題と関係があるか」「実行できる根拠はあるか」「どう相談するか」。ページの順番は、そのまま提案の順番です。色や余白を決める前に、この構造を決めました。

１日という速さは、ここで目的を共有し、文章・デザイン・実装の往復を短くできたことが大きいですね。最初の実装を形にした後も、読んで分かりにくい箇所や操作を磨いています。速く形になるほど、具体的な改善に早く入れます。

会社の事業資料、技術実績、現在のテンプレート、参考にする画面、そして依頼の意図です。コンテキストとして、まず事実を共有する。その上で「自治体だけでなく中小企業にも伝える」「実績と提案内容を混同しない」「相談までの流れをつくる」といった判断基準を渡します。

使ったのは、コードを提案するだけでなく、リポジトリを読み、ファイルを変更し、コマンドやブラウザーを操作できるAIです。事業資料を読ませ、実装案をつくり、構文を検査し、画面を撮って、修正する。AIを「回答する道具」から、検証まで動く開発の相棒へ変える。この実行のループを、制作の中心に置きました。

「プロっぽくして」だけでは、どこを直せば完成なのか曖昧です。そこで、見出しの優先順位、文字の開始位置、カードの役割、スマートフォンでの並び方まで、画面を見ながら条件に変えていく。曖昧な要望を、確認できる仕様へ翻訳するのがエンジニアの仕事です。

たとえば、８週間の取り組みと成果の評価を、同じ色のカードで連続して見せたら、見た目は整っていても意味の違いが伝わりにくい。そこで「時間の流れ」と「成果を確かめる視点」を別の見せ方にしました。生成したパーツを並べるだけでは、この文脈はつながらないんです。

2026年9月に公開されたCoinbaseの事例でも、既存コンポーネントとデザインの対応情報が、エージェントの選択を助けています。今回の方法は事業資料とコード、画面を渡す形ですが、私が重視するのも同じで、AIが推測しなくてよい情報を増やすことです。出典：Figma / Coinbaseの検証

私は普段、JavaだけでなくGoやRubyを使い、SaaSの開発やSREにも携わっています。だからこそ、今回の要件に必要な構成を選びます。既存サイトにはWordPressの投稿管理、URL、編集の仕組みがある。そこを使うことで、担当者が更新を続けられるホームページになります。

Newsは専用のカスタム投稿タイプとして設け、大分類とテーマのタグは別々の分類データにしました。タイトルにラベルらしい文字が見えていても、絞り込みは見た目の文字列に依存させない。記事本文は管理画面で編集し、一覧と詳細のテンプレートが共通のデータを表示します。

ここを全部HTMLへ埋め込むと、次の記事を出すたびに開発作業になります。速く作ることと、次も速く更新できることを、同じ設計で実現する。データと表示を分けた理由はそこです。公開日や更新日も、その場で書いた固定値ではなく投稿の情報から表示します。

初期記事の登録にもWordPressのAPIを使い、同じ記事が存在すれば重複登録を避ける。再実行で同じ結果に落ち着く冪等性は、SaaSのバッチや外部連携でも意識する考え方です。小さなコーポレートサイトでも、運用に効く設計は共通しています。

ありました。新しい記事の見出しに、意図しない線が出る。タイトルの位置がずれる。余白を入れたはずのカードが詰まる。単独のHTMLとしては成立しても、既存のWordPressテーマへ組み込むと、共通CSSの影響を受けるんです。

今回も、見出しへ付く疑似要素や、共通ルールのdisplay、sectionの余白指定が、新しい記事の装飾と競合していました。画面上の症状からDOMを見て、計算済みスタイルをたどる。どのセレクターが勝っているかを調べ、Newsの範囲に絞って修正する。こういうところは、地味ですが面白いですね。

AIの出力が正しいかは、組み込んだ環境で決まります。新しいCSSだけを眺めても、既存テーマとの関係は見えません。スクリーンショットとコードの両方を確認するのは、そのためです。

質問ラベルと質問文も、別の要素に分けて縦に配置しました。ラベルを文頭に押し込むと、長い日本語の質問で折り返しが不自然になります。見出しの位置、本文の行幅、余白を整えることで、技術記事の長さを読みやすさへ変えていきます。

タイトルだけでなく、本文にしか出てこない言葉でも探せるようにしています。さらに分類、タグ、年度を組み合わせる。ここで検索条件と一覧の条件が別々に動くと、「表示件数は合っているのに２ページ目で違う記事が出る」といった不具合につながります。

WordPressのpre_get_postsフックで、WP_Queryのメインクエリを、Newsの一覧であるときだけ調整しています。is_main_queryとis_post_type_archiveで適用範囲を限定し、既存Blogの検索には影響させません。キーワードを検索条件へ渡し、分類とタグはANDで組み合わせ、年度と公開範囲も同じクエリに載せる。20件というページサイズも共通の定数にします。表示用の配列を後から切り分けるより、件数とページ数をそろえやすい設計です。

並び順は公開日の降順にし、同じ日時の記事はIDでも順序を確定させます。日付が同じ記事が増えたとき、境界で順番が不安定にならないためです。ページ送りのURLにも検索条件を引き継ぐので、共有したリンクやブラウザーの戻る操作から、同じ条件に戻れます。

テストでは公開記事を22件用意して、１ページ目が20件、２ページ目が２件になるかを確認しました。下書き、非公開、パスワード付きの記事が混ざらないかも見る。「検索できた」から、「見えるべき記事だけが、最後まで探せる」へ。この違いに、実装の品質が出ます。

まず、記事本文や主要リンクをサーバーが返すHTMLに含めます。読むためにJavaScriptの実行を待つ構成にはせず、JavaScriptは目次の補助や共有などに使う。これは読み手にとっても、内容を取得する仕組みにとっても扱いやすい形です。

タイトル、説明文、正規URL、公開日、更新日、著者・監修者を整理し、画面で示す情報と構造化データをそろえます。同じ記事の情報を何か所にも手入力すると、更新時にずれます。投稿データから共通して生成する設計が効いてきます。

絞り込みの組み合わせは便利ですが、それぞれを独立した記事のように検索へ出す必要はありません。記事の正規URLを明確にし、サイトマップには公開記事と実際の更新日時を載せる。画像には寸法と内容を説明する代替テキストを付け、共有したときにも内容が分かる画像を設定します。

GoogleはAI検索でも基本的なSEOを重視し、独自の価値がある内容を推奨しています。そこで今回の記事には、一般論だけでなく、実際の設計判断、起きた不具合、確認した条件を書きました。検索される言葉と、読んで役立つ具体性をつなぐ。私たちが実装で積み上げられるのは、そこですね。出典：Google Search Central / AI検索とウェブサイト

確認する層を分けます。PHPやJavaScriptの構文、WordPressの検索結果、ブラウザーでの操作、そして画面の見え方です。たとえば構文チェックが成功しても、スマートフォンでボタンが押せるとは限りません。それぞれ別の問いとして確認します。

検証にもAIの実行能力を使います。変更したコードの構文チェック、検索条件を変えたリクエスト、複数の画面幅での撮影を連続して実行し、失敗した条件を修正の入力へ戻す。ただし、AIが「成功」と説明したことを合格条件にはしません。返ってきた件数、HTTPの応答、DOM上の状態と、実際の画像を確認します。

ブラウザーではPlaywrightを使い、画面幅を変えて表示、画像の読み込み、検索フォーム、補足のポップアップなどを確認しています。用語説明はマウスを当てるだけでなく、キーボードでフォーカスしても、スマートフォンでタップしても開く。Escapeや外側の操作で閉じられるところまでが一つの機能です。

画像も、ファイルが存在するだけでは不十分です。実際に表示されるサイズやトリミングを見て、スクリーンショットの中身が読み込まれているかを確かめる。画像を差し替えたのに古いものが見えている場合には、キャッシュの扱いまで確認します。ブラウザーに届くまでを見ないと、完了したとは言い切れません。

これはSaaSの現場ともつながります。GoのAPIでもRailsの業務処理でも、入力、状態、出力、失敗時の動きを考える。画面が変わっても、境界を調べる思考は同じです。AIが実装を速くするほど、何を検証するかという設計の価値が上がる。今回、あらためて実感したことです。

海外の速い開発事例も、そこまで読むと面白いんです。Nursaの事例は週末でMVPを形にした後、企業向けにさらに２週間磨き込んだと説明しています。Lovableの自社移行記事には、段階的な切り替えとメモリ制約による障害まで書かれている。速さの見出しを、運用の話まで読んで初めて、自分の実装に持ち帰れる知見になります。出典：Nursaの制作事例出典：Lovableの移行記録

まずは、困っている仕事を一つ、具体的に聞きたいですね。情報発信を変えたいのか、手作業を減らしたいのか、社内に技術を使える人を育てたいのか。それによって、つくるものも、技術の選び方も変わります。ホームページ制作、業務システム、AI活用、研修を別々の箱に入れず、課題に合わせて組み合わせていきます。

人材育成でも、AIに指示を出して画面ができた、で終わらせたくありません。つくったものを説明できるか、相手の反応から直せるか、仲間と役割を分けて届けられるか。「つくる・届ける・つながる」を、動く成果物と対話で身につける。その支援に、現役の開発者としての経験を活かします。

不登校などで学びの機会を必要としている方への取り組みでも、その人に合う入口を、支援に関わる方々と考えたい。技術を伝えることは、選べる道を増やすことでもあります。自治体の担当者にも、中小企業の経営者にも、「こんなこと、できますか」と相談してもらえる存在でありたいですね。

AIと一緒につくると、考えたことが目の前で動き始める。その面白さは、ぜひ体験してほしいです。私はこれからもコードを書きますし、運用も見ます。その知見を、現場の仕事と、人が育つ機会へつなげていきたいと思っています。