WordPress

Project N26について、今週は「実装を進める」よりも「要件を考え直す」の時間を多く取っている。投稿画面を有するウェブ・アプリケーションとして考えてきたけれど、ファイルに記事を書く方がいいかもなあ。って考えていくとStatic Site Generator的なアプローチに落ち着くのかも。

なにしろ、AI Agent時代にファイルはとても強い。grepやsedで操作できると取り回しコストが極端に低くなるよね。ってのを、きのうから試している「エージェントにWikiを書かせる」を体験して強く実感しているところ。

WordPressでブログを運用していたとき、記事へのタグ付けをけっこうがんばっていて。でもさ、記事が増えてくると「今日のこの記事にこのタグをつけたら、過去のあの記事とあの記事にも…」とさかのぼって反映するコストが高くなってしまっていた。これがファイルであれば、数百記事があってもAI Agentに「過去記事で同じタグをつけた方がいいやつはあるかな」とか適当に相談して「じゃあそれで」って指示してやれば1分もかからずに対応できると思う。

「記事のファイル群 + SQLite」くらいの感じで、データ・ポータビリティの高いサイトの設計を考えてみるか。

ぼくはGenerative AIなどなどの発展によってソフトウェアの活用がさらに民主化されていったらうれしいと思っている。現状は、ソフトウェアエンジニアがソフトウェアに対する特権を握っている状態だと思うので、もっと手放していきたい。

そんなモチベーションもあり、ソフトウェアをやっていきたい人の相談に乗る機会もけっこうある。今日も、以前にGemini CLIの使い方をレクチャーした相手から相談を受けてあれこれを進めていた。しかしまあ、専門領域の民主化ってのはそんなに簡単なものでもないよな、ってのは最近よく思う。Gemini CLIでもClaude Codeでも、なんだったらChatGPTでもいいんだけど、そういうのを使ってたとえばウェブページをつくったとして。そこまでは簡単にいけるんだけど、ちょっとずつ手を加えていくとか、単一のウェブページから構造化されたウェブサイトに発展させていくとなると、Generative AIを適切に活用するのが一気にむつかしくなるポイントがある。

「壊してもいいようにGitでバージョン管理しながら進めたいな」とか「そろそろStatic Site Generatorに切り替えた方が楽だよな」とかとか。じゃあWordPressを導入しますか、となっても手作業がいっぱいあってGenerative AIはナビとして活用できるくらいに留まるもんね。高速道路の先の渋滞って感じがする。