AIの記事を書くために、AIと一緒に更新の仕組みを作った

当社では、AIやデジタル技術を河川設計の実務でどう使っているかを、少しずつ外部へ発信することにしました。

ところが、記事を書き始める前に別の問題が出てきました。

記事を追加するたびにHTMLを編集し、一覧ページへリンクを足し、公開後に修正があれば同じファイルをもう一度触る。数本なら何とかなりますが、10本、20本と増えれば、記事を書くことより更新作業の方が面倒になりそうです。

そこで、最初の記事を書く前に、記事を継続して公開できる仕組みから作ることにしました。

使ったのはChatGPTとCodexです。

サイトを作り直したかったわけではない

当社には、すでに公開中のコーポレートサイトがあります。

会社概要や事業内容などを掲載し、既存のURLも外部へ案内しています。技術記事を載せるためだけに、サイト全体を別サービスへ移したり、全面的に作り直したりする必要はありませんでした。

欲しかったのは、現在の見た目とURLを大きく変えずに、記事だけを増やせる仕組みです。

検討した結果、記事はMarkdownで作成し、公開用のHTMLへ変換する方法を採用しました。ローカル環境でサイトを生成し、完成した静的ファイルを従来どおりサーバーへアップロードします。

新しい仕組みを入れること自体を目的にせず、今ある運用をなるべく壊さないことを優先しました。

「ブログを追加して」だけでは足りなかった

私はプログラマーではありません。専門は河川設計で、Webシステムを体系的に学んだ経験もありません。

そのため、最初から技術構成を決めてCodexへ渡したわけではありません。まずChatGPTとの会話で、何を残し、何を変えるのかを整理しました。

• 既存サイトの見た目は大きく変えない
• 現在公開しているURLを維持する
• 記事はMarkdownで管理する
• 記事一覧と個別ページを自動生成する
• 公開前にローカルで確認する
• 特別なサーバー機能へ依存しない
• 更新方法を担当者だけの暗黙知にしない

こうした条件を言葉にしてから、Codexへ実装を依頼しました。

「ブログ機能を追加してほしい」とだけ伝えても、技術的には動くものができるかもしれません。しかし、それが当社のサイト運用に合うとは限りません。

コードを書けない立場でも、目的、制約、完成条件は決める必要があります。むしろ、そこが曖昧なままではAIも正しく作れません。

一度で完成するほど甘くなかった

実装後、すぐに記事を公開できたわけではありません。

ローカル確認用の起動方法では、トップページが正しく表示されないことがありました。記事データの記述を直したら、今度はサイト生成時にエラーが出ました。

公開対象ではない作業用の注記が、生成後のHTMLへ混ざっていないかを確認する仕組みも後から追加しました。

文章についても同じです。

AIが作った原稿の中に、実際の経験と少しずれた説明がありました。図面から座標を取得した事例では、AI画像認識で数値を読み取ったのではありません。図面内に存在する構造化データを処理し、必要な形へ変換したものです。

文章として自然でも、実体験と違えば公開できません。

AIが作ったコードも文章も、動いているように見えるだけでは足りません。こちらが正しい状態を分かっていなければ、間違いにも気づけません。

既製サービスへ移るより、必要な部分だけ作った

記事公開だけなら、既製のブログサービスを使う方法もあります。

ただ、今回はサイト全体を移したいわけではなく、既存サイトへ記事運用だけを追加したいという条件でした。

既製サービスが悪いのではありません。一般向けに用意された便利な機能と、当社が今必要としている範囲が少し違っただけです。

そこで、サーバーへの公開方法など現在使えている部分は残し、Markdown管理、ページ生成、公開前確認といった不足部分だけを追加しました。

自社向けの仕組みを作ることは、何もかも一から開発することではありません。既存の環境やサービスを使いながら、自社固有の不便だけを補う方法もあります。

バイブコーディングというより、AIとの対話型開発だった

AIへ要件を伝えながらシステムを作る方法は、一般にバイブコーディングと呼ばれることがあります。

ただ、今回の取り組みを振り返ると、当社の実感に近いのは「AIとの対話型開発」です。雰囲気や雑談だけで作ったのではなく、目的と制約を伝え、実装結果を確認し、問題を言葉にして修正する作業を繰り返しました。

曖昧なお願いだけで完成品が出てくる方法ではありませんでした。

1. 目的を整理する
2. 現状の制約を伝える
3. AIに実装させる
4. 実際に動かす
5. 違和感や不具合を言葉にする
6. 修正させる
7. もう一度確認する

この繰り返しです。

コードを一行ずつ書かなくても、「何を作るのか」「何が正しいのか」「どこまでなら運用できるのか」を判断する仕事は残ります。

実務で何が面倒なのか、どの作業を変えると危険なのか、今ある運用のどこを残すべきか。これは、コードの知識だけでは決められません。

完成したのは、3本の記事ではなかった

最初に公開した技術ノートは3本でした。

ただ、本当の成果は3本の記事そのものではありません。

次の記事をMarkdownで追加し、サイトを生成し、表示と内部情報の混入を確認して公開する。その流れを繰り返せるようになったことです。

記事一覧や個別ページを毎回手作業で組み立てる必要もなくなりました。原稿を仕上げる作業と、サイトへ掲載する作業も分けられます。

小さな会社では、大規模なシステムを導入するより、毎回発生している小さな作業を減らす仕組みの方が効くことがあります。

今回作ったのは、立派なWebシステムというより、次の記事から少し楽になる運用の土台です。

AIの記事を書くために、AIと一緒に記事公開の仕組みを作る。

少し回り道にも見えますが、この回り道ができたことで、これからは記事を書くことそのものへ時間を使えるようになりました。