PukiwikiにMarkdownと下書き機能を統合した
pukiwiki Markdown claudecode AI
長年使ってきたPukiWikiに、ようやくMarkdown対応と下書き機能を統合しました。PukiWiki記法は独特で覚えにくいという声をよく聞きますし、ぼく自身もときどき記法を忘れて調べ直すことがあります。Markdownであれば多くの人が使い慣れているので、記事を書くハードルが下がるのではないかと考えていました。
なぜMarkdown対応が必要だったのか
PukiWikiは2000年代から続く老舗のWikiエンジンで、日本では根強い人気があります。しかし、記法が独特なのが難点です。見出しはアスタリスク、リンクは二重括弧、強調はシングルクォート2つなど、他のマークアップ言語とは異なるルールを覚える必要があります。一方でMarkdownは、GitHubやQiita、Zennなど多くのプラットフォームで採用されており、エンジニアにとっては事実上の標準になっています。
ぼくの運営するoncologynote.jpでは、医療系の記事を書くことが多い（最近はそうでもない？）のですが、Pukiwiki記法を気にしながら書くのは意外とストレスになります。Markdownであれば、VSCodeでもObsidianでも、好きなエディタで下書きを書いてからコピペできます。そこで、PukiWikiの既存機能を壊さずにMarkdown記法を使えるようにする改造に取り組むことにしました。
2つのプロジェクトの統合
今回の統合作業では、これまでにGitHubで公開していた2つのプロジェクトを組み合わせました。
pukiwiki_draftは、PukiWiki 1.5.4に下書き保存と自動保存機能を追加するプロジェクトです。30秒ごとの自動保存機能があり、編集中にブラウザを閉じてしまっても下書きから復帰できます。手動での下書き保存ボタンもあり、まだ公開したくない記事を保存しておくことができます。
pukiwiki154_mdは、PukiWiki 1.5.4にMarkdown対応を追加するプロジェクトです。league/commonmarkというPHPライブラリを使ってMarkdownをパースし、HTMLに変換します。編集画面にはEasyMDEというWYSIWYGエディタを組み込んでおり、プレビューを見ながらMarkdownを書くことができます。ページの先頭に#notemdというタグを置くことで、そのページがMarkdownモードであることを示します。
どちらのプロジェクトも単独では動作するのですが、両方を同時に使おうとすると競合が発生します。特にplugin/edit.inc.phpという編集画面を制御するファイルは、両方のプロジェクトで大幅に変更されているため、単純にマージすることはできませんでした。
Claude Codeを使った統合作業
統合作業はClaude Codeを使って進めました。plugin/edit.inc.phpでは、下書き保存ボタンの追加、自動保存機能の組み込み、Markdownチェックボックスの追加など、複数の機能を同時に扱う必要がありました。lib/convert_html.phpではMarkdownからHTMLへの変換処理を担当しており、PukiWikiの脚注記法をMarkdownのインライン脚注に変換する前処理なども含まれています。lib/html.phpでは編集フォームの生成とEasyMDEエディタの初期化を行っています。
Codexによるコードレビュー
統合後、OpenAIのCodexにコードレビューを依頼しました。Codexはコードの問題点を指摘してくれるAIツールで、人間のレビュアーが見落としがちな問題を発見してくれることがあります。実際、今回のレビューでは複数の問題が指摘されました。
最初のレビューで指摘された問題のひとつは、CSRF対策に必要なget_ticket()とcheck_ticket()という関数が未定義だったことです。これらの関数はpukiwiki_draftで使用されているもので、下書き保存時のセキュリティを担保するために必要でした。lib/init.phpに追加することで解決しました。また、Markdownモードを示す#notemdタグの処理が不完全で、チェックボックスの状態が保存されないという問題もありました。この問題についてはGeminiにも意見を求め、より包括的な修正方針を採用しました。
URL検証が厳しすぎるという指摘もありました。Markdown内のリンクを検証する際、相対パスや#で始まるアンカーリンク、mailto:やtel:といったスキームを弾いてしまっていたのです。これらは正当なリンクなので、検証ロジックを緩和する必要がありました。
複数ラウンドのレビューと修正
Codexのレビューは一度では終わりませんでした。最初の修正を適用した後、再度レビューを依頼すると、また新たな問題が見つかりました。add/add_topという既存ページへの追記モードを使った場合に、#notemdタグがページの途中に挿入されてしまうという問題です。PukiWikiでは既存ページの先頭または末尾に追記する機能があるのですが、この場合に#notemd処理の順序が適切でなかったのです。
コードフェンスの判定にも問題がありました。Markdownではバッククォート3つまたはチルダ3つでコードブロックを作れますが、これらを単純なトグルで処理していたため、両者が混在すると誤判定が起きる可能性がありました。CommonMarkの仕様に準拠するよう、開始と終了で同じ文字を使い、終了フェンスは開始と同じかそれ以上の長さであることをチェックするように修正しました。また、CommonMarkでは先頭に0〜3スペースのインデントが許容されるので、これにも対応しました。
3回目のレビューでは、プレビュー時にMarkdownチェックボックスの状態が保持されないという問題が見つかりました。プレビューボタンを押すとチェックが外れてしまい、次の送信でMarkdownモードが解除されるという困った挙動です。これはedit_formに渡すテキストに#notemdが含まれていなかったことが原因でした。また、空本文でMarkdownチェックをONにしていると、ページ削除ができなくなるという問題もありました。これは#notemdタグが自動的に付与されてしまい、本文が空でなくなるためです。
このように、Claude Codeが書いたコードをCodexとGeminiでレビューする、そのレビュー結果をClaude Codeに再度投入して修正させる、それを再度CodexとGeminiにレビューさせるということを繰り返したわけです。ちなみに、何度か繰り返すとこの3種類のAIの中ではバグを見つける能力はCodexがダントツ高いように感じられました（他の2つのAIでは指摘できなかったバグをCodexだけが指摘するということが何度もあった）。
AIによるコードレビューの有効性
今回の経験を通じて、AIによるコードレビューの有効性を実感しました。人間のレビュアーであれば見落としそうな細かいエッジケースを、Codexは的確に指摘してくれます。特にadd/add_topモードでの#notemd処理や、空本文時の挙動など、通常のテストでは見つけにくい問題を発見できたのは大きな収穫でした。
一方で、AIのレビュー結果をそのまま鵜呑みにするのも危険です。Geminiにも同じコードをレビューしてもらったところ、Codexとは異なる観点からの指摘がありました。特に#notemdの処理については、Geminiの方がより具体的な修正箇所と挿入位置を示してくれたので、そちらを採用しました。複数のAIの意見を照らし合わせることで、より確実な修正ができると感じています。
Claude Codeを使って修正を実装し、Codexでレビューし、問題があれば再度Claude Codeで修正するというサイクルを回すことで、品質の高いコードに仕上げることができました。最終的にはCodexによる修正提案もそのまま取り込み、Claude Codeがレビューするという逆パターンも試しました。AIが書いたコードをAIがレビューし、さらに別のAIが修正するという、ちょっと不思議なワークフローですが、結果的には人間が一人で作業するよりも多くの問題を発見・修正できたと思います。
この記事に対するコメント
このページには、まだコメントはありません。
更新日：2025-12-29 閲覧数：233 views.