こんにちは。PyCon JP 2026 広報チームの Nakamura です。
PyCon JP 2026 の公式サイト（https://2026.pycon.jp）は、今年あらたに作り直しました。一番こだわったのは、デザインや最新の技術ではなく 「Web 担当以外の主催メンバーが、自分でサイトを更新できること」 です。
この記事では、そのために入れた工夫を 3 つ紹介します。
なぜそこにこだわったのか
カンファレンスのサイトは、開催が近づくにつれて更新が一気に増えます。託児やランチの案内、会場やアクセスの情報、関連イベント、当日の過ごし方……。文章を書くのは各チームなのに、サイトに載せる作業が Web 担当に集まると、そこで渋滞します。
2025 年のサイトでも、本文は Markdown で書けるようになっていました。ただし Markdown ファイルはソースコードと同じ場所（GitHub）に置かれていたので、更新するには Git の操作と変更依頼（プルリクエスト）が必要でした。主催メンバー全員が Git に慣れているわけではないので、結局は Web 担当が代行することになります。
「じゃあ WordPress のような既存の CMS を使えば？」という案も当然あり、ここは議論になりました。最終的に採用しなかった理由は 運用コスト です。カンファレンスの主催メンバーは全員が別に仕事を持っていて、サーバーやプラグインの更新をフルタイムで見張り続けることは現実的に難しい。できるだけ「動かし続けるための手間」が小さい構成にしたかったのです。
そこで、
- 文章は Markdown で書く
- ただし置き場所は GitHub ではなく Google ドライブ（主催メンバー全員が普段から使っている）
- サイトは静的なファイルとして書き出して、Cloudflare Pages で公開する
という形にしました。公開しているのはただのファイルなので、アクセスが増えても重くなりませんし、プログラムやデータベースを常時動かすことに伴う手入れも要りません。
もちろん、これで安全が手に入るわけではありません。ソースコードを置いている GitHub や、本文を置いている Google ドライブ、各種サービスのアカウントが乗っ取られれば、そこからサイトを書き換えられます。守る対象が「常時動いているサーバー」から「主催メンバーが使っているアカウントと権限」に移るだけです。そのぶん、各サービスの権限設定や、サイト側から読み取る範囲の管理には気をつけました。
全体の流れはこうなっています。
スポンサーや主催メンバーの一覧は、各チームがもともと管理している Google スプレッドシートから取り込んでいます。ロゴや顔写真も Google ドライブです。シートには画像の ファイル名だけ 書いてもらい、同じ名前の画像をドライブに置けば表示される、という約束にしました。「どの画像がどの行に対応するか」の対応表を別に作らなくて済むようにするためです。
以下、工夫した 3 点を紹介します。
工夫 1: Markdown を置けばページができる
ドライブのフォルダに Markdown ファイルを置くと、それがそのままサイトのページになります。ページは 2 種類の作り方を用意しました。
よく使うのは、行動規範やアクセス案内のような「URL が決まっているページ」です。 開発側で「この URL はこのファイル名」という対応を 1 行だけ登録しておきます。あとは担当者がドライブに coc.ja.md と coc.en.md を置けば、日本語版と英語版のページができます。ページごとのプログラムは書きません。
もう一つは、お知らせ（ニュース）のように増えていくページです。 こちらはファイルを置くだけでページが増えます。ファイル名を 2026-04-12-launch.ja.md のようにすると、日付が公開日、残りの部分が URL になります。日付をファイル名に入れるルールにしたのは、ドライブでファイルを並べたときに日付順になり、書き忘れも起きないからです。
ページの見出しも、SNS でシェアされたときに出る説明文も、Markdown ファイルの先頭に書いた項目から作られます。つまり 担当者は文章を直すだけで、ページの見出しから SNS 用の説明文まで更新できます。
下書きはファイル名の先頭に draft. を付けるだけ
公開前に見た目を確認したいときは、ファイル名の先頭に draft. を付けます。
coc.ja.md… 本番draft.coc.ja.md… 下書き
下書きは 検証環境にだけ表示され（「DRAFT」のバッジが付きます）、公式サイトには出ません。内容が固まったら、ドライブ上でファイル名から draft. を外すだけで公開 されます。
下書き用のフォルダを別に作る方法もありましたが、「移動し忘れる」「どっちが新しいのか分からなくなる」が起きやすいので、同じフォルダに並べて名前で区別する形にしました。
メニューは「文章があるページ」だけに出る
メニューには、まだ準備中のページも含めて最終形の項目を最初から全部登録してあります。ただし Markdown ファイルが用意されたページだけがメニューに出る 仕組みにしました。
おかげで、新しい案内ページを公開するときもメニューをいじる必要がありません。文章ができたら載る、できていなければ出ない。「リンクはあるのに中身が無い」も「ページはあるのにどこからも行けない」も起きません。
結果
案内ページの数を 2025 年と比べると、6 ページから 27 ページに増えました（スポンサーや主催メンバーの一覧など、スプレッドシートから作っているページは除いた数です）。お知らせも、今年から Markdown で書けるようになりました。
ページを増やすのに Web 担当の作業が必要なくなったぶん、各チームが書きたいことを書けるようになった結果だと思っています。
工夫 2: 表示イメージを確認できるエディタを自作した
Markdown をドライブに置く方式には、ひとつ弱点があります。Google ドライブだけでは、サイトに載ったときの見た目が分からない のです。Markdown は記号で書式を表す書き方なので、ドライブ上では「## という記号が付いた文章」に見えるだけで、見出しの大きさや表の体裁は想像するしかありません。
そこで、ドライブ上の Markdown をブラウザで直接編集できるエディタを自作しました。 画面は左に文章、右にプレビューが出ます。
このエディタの一番のポイントは、プレビューが公式サイトとまったく同じデザインで表示されること です。見出しの大きさ、文字の色、表の枠線まで公式サイトと同じ部品を使っているので、「保存したらこう見える」がその場で分かります。 本文に貼った画像も、ボタンを押すとドライブから読み込んでプレビューに表示されます。
作りとしては、このエディタもサーバーを持っていません。ブラウザから Google にログインして、ブラウザが直接ドライブを読み書きします。公式サイト側とエディタ側が共有しているのは 「ドライブ上のファイル名のルール」だけ です。エディタが動かなくなってもサイトは問題なく公開でき、その逆も同じ。運用の手間を増やさないという最初の方針どおりです。
ほかに、誰かが同じファイルを同時に編集していたら警告して勝手に上書きしない、といった配慮も入れています。
反省：編集方法は一本化してよかった
当初は「人によって使いたいツールは違うだろう」と考えて、好きな方法で Markdown を編集できること を優先していました。手元のエディタで書いてドライブにアップロードしてもいいし、他のツールを使ってもいい、という前提です。
ところが実際に運用してみると、ほとんどの人が自作エディタだけを使っていました。 手元の Google ドライブをパソコンにマウントして Emacs や vi で直接編集していた人もいましたが、少数でした。ならば最初から「編集はこのエディタで」と一本化し、その前提で作り込んだほうが、案内も説明も単純になったはずです。選択肢を残したことが、かえって説明を増やしてしまいました。
一方で、エディタ自体の評判は良く、「便利になった」というフィードバックをもらえました。見た目を確認しながら書けることが、やはり効いていたようです。
工夫 3: サイトへの反映は Slack から
このサイトは、あらかじめ HTML ファイルを書き出しておく方式です。そのため ドライブで文章を直しただけでは、まだサイトは変わりません。 「組み立て直す」操作が必要です。
ここを Web 担当への依頼にしてしまうと、結局また渋滞します。そこで Slack のスラッシュコマンドで、主催メンバーの誰でもサイトの組み立てを実行できるようにしました。 Slack に /deploy と打つだけです。
主催メンバーのやりとりはもともと Slack に集まっているので、「サイトを更新したい」と思った場所から離れずに実行できます。新しい管理画面にログインしてもらう必要もありません。
/deploy は引数で行き先を指定できるようにしていて、主催メンバーだけが見る検証環境へ反映するか、公式サイトへ反映するかを選べます。誰が実行したかと、成功したかどうかも Slack に通知されるので、作業が重なっても状況が見えます。
仕組み自体は単純で、Slack からのリクエストを受け取る小さなプログラム（Python です）を用意し、それがサイトの組み立てを開始させているだけです。Slack からのリクエストであることを確認してから実行するようにしています。
これで、文章を書いた人が検証環境での確認から公開まで自分で完結できるようになりました。
まとめ
PyCon JP 2026 のサイトでは、
- Markdown を Google ドライブに置けばページになる ようにして、更新に Git も CMS も不要にし、Web 担当以外の主催メンバーみんなが使えるようにした
- 公式サイトと同じ見た目でプレビューできるエディタを自作 して、「載ったときの姿」を確認しながら書けるようにした
- 公開は Slack のコマンドから にして、書いた人が公開まで自分で完結できるようにした
という形で、Web 担当以外のメンバーがサイトを更新できるようにしました。結果として案内ページは 6 ページから 27 ページに増え、「便利になった」という声ももらえました。
一方で、「好きなツールで編集できる」ようにした部分はほぼ使われず、最初からエディタに一本化しておけばよかったという反省も残りました。
こうして主催メンバーみんなで育ててきたサイトです。よかったら覗いてみてください。
PyCon JP 2026 公式サイト: https://2026.pycon.jp
来年以降のサイト作りの参考になればうれしいです。
