武丸と重五郎屋サイト構築

序110バイトの謎

本番公開の直後、追加改修の差分を上書きする前の確認として、サーバー上の top.js のサイズを手順書の値と照らし合わせた。手順書が求めていた値は6,898バイト。FFFTPの一覧にも6,898バイトと表示されていた。ところが、念のためPCにダウンロードしたファイルは7,008バイトだった。

top.js

サーバー側：6,898バイト
PC側：      7,008バイト

差は110バイト。誰かが本番のファイルを書き換えたのか、それとも別の版が混ざったのか。サーバー上で誰かがファイルを直接編集した可能性を疑うべき状況である。

答えは、ファイルの中身ではなく転送経路にあった。Claudeが納品した top.js は、LF改行で110行ある。FTPのテキスト（ASCII）モードでダウンロードすると、各行のLFがCRLFに変換され、1行につき1バイトずつ増える。6,898 + 110 = 7,008。FFFTPをバイナリモードに切り替えて取得し直すと、サイズは一致した。

この記録は、こうした小さな食い違いを一つずつ潰しながら、二つの古いWebサイトを作り直した過程の実録である。

01二つのサイト、二つの技術的負債

同じ南伊豆・中木の渡船サイトでも、二つのサイトが抱えていた問題は性質がまったく違った。

重五郎屋：時間が止まった静的HTML

旧サイトは古い作り方の静的HTMLだった。固定幅830pxのレイアウト、TABLEによる段組み、GIF画像、<font>タグ、インライン属性。船長の紹介、写真、連絡先、ブログ、Facebook、アクセスマップといった情報は揃っていたが、スマートフォンでの閲覧を前提としない設計だった。

武丸：役目を終えつつあったWordPress

武丸の問題は、デザインの古さではなかった。10年近く積み重ねた釣果記事、画像、パーマリンク、検索エンジンからの流入を、どうやって壊さずに残すか。課題の中心はデータの保全にあった。

02同居人の多いサーバー

hirizo.sakura.ne.jp

/home/hirizo/
└── www/
    ├── j568/        ← 重五郎屋
    ├── takemaru/    ← 武丸（当時はWordPress）
    └── その他の既存サイト・古いCGIなど

同じサーバーには、今回の対象ではないサイトや古いCGIも動いていた。このため、最初に次の制約を決めた。

1. サーバー全体のPHPバージョンや設定を変更しない
2. 稼働中のほかのサイトには触れない
3. MySQLとWordPressの既存データを削除しない
4. 本番に切り替える前に、別のディレクトリで動作を確認する
5. 問題が起きたら短時間で元に戻せる構成にする
6. 秘密情報はDocumentRootの外に置く

もう一つのサーバー、Xserverで運用している nakagi.jp（この記事を載せているサイト）は、今回の作業とは別の環境である。

03重五郎屋――AmebloをCMSにするAmeblo RSS → PHP → JSON → 静的HTML

重五郎屋では、WordPressもデータベースも新しく導入しなかった。公開側はHTML・CSS・JavaScriptだけで作り直した。デザインの制作はClaudeが主に担当し、ChatGPTは既存構成の把握、サーバー操作の案内、実機での確認、問題が起きた際の切り分けを担当した。

記事を書く場所は変えない

重五郎屋は、もともとAmeblo（アメブロ）で情報を発信していた。新しいサイトのために別の管理画面を覚えてもらう理由はない。そこで、AmebloのRSSをサーバー側で取得し、ホームページに反映する構成にした。

https://rssblog.ameba.jp/tosen15rou/rss20.xml

Ameblo
   │  RSS（rss20.xml）
   ▼
さくらサーバーのPHP（CRON 毎時5分）
   │  XMLを解析してJSONを生成
   ▼
/home/hirizo/www/j568_data/blog.json
   │  JavaScriptで読み込み
   ▼
重五郎屋の静的HTML（/j568/）

取得テストでは、記事10件と、本文・写真のURLを確認した。トップページには最新記事5件を、本文の概要と写真付きで表示している。

磯場の写真をどこまで共有するか

武丸のサイトでも、同じ中木の磯場を案内する。そこで、重五郎屋の磯場写真と航空写真を武丸でも使うことになった。調査すると、単純に共有できない問題が2つ見つかった。

• 重五郎屋の磯の説明文には、重五郎屋だけに当てはまる内容が含まれていた（例：「重五郎屋のお客さんには人気」）。武丸のサイトにそのまま載せると、事実と違う案内になる。
• 全沖磯航空写真 202508_14.jpg には、そうした説明文が画像そのものに書き込まれていた。さらに、重五郎屋の磯場案内20か所にない「山越」「ヒカゲ」も記載されていた。

本番切り替えで起きたこと

完成した静的サイトは別のディレクトリで確認したうえで、/j568/ に反映した。この時、サーバーに古い版の index.html が残っていたために、新しい表示が反映されない問題が起きた。サーバー上のファイルの版を確認し、最新版で上書きして解決している。

04武丸――WordPressをやめるという判断

武丸でも最初は、WordPressのまま見た目を改善する選択肢があった。しかし、更新の主体はすでにInstagramに移っていた。WordPressに残っていた役割は、過去記事の保管と、既存ページの表示だけだった。

データベースを調べると、もう一つ分かったことがある。「以前、知人がInstagramとの連携を設定したらしい」と伝えられていた仕組みの実体である。

WordPressを維持すれば、古いPHPとMySQL、テーマ、プラグイン、管理画面の保守が続く。静的化すれば、公開部分の動的な処理を大きく減らせる。最終的に、次のように役割を分けた。

過去の釣果記事    → WordPressから静的HTMLへ変換
新しい釣果投稿    → Instagramを入力元にする
Webサイトの表示   → HTML / CSS / JavaScript
データの更新      → PHP / CRON / JSON

これはデザインの刷新ではなく、更新方式そのものの変更である。ただし、WordPressの廃止は「過去記事の静的化が合格基準をすべて満たした場合に限る」という条件を付けた。

051,326件の過去記事を静的HTMLにする

旧WordPressのデータベース（SnapUPで取得した snapshot/db.sql、約8.4MB）を、作業環境で読み取り専用で解析し、公開記事を抽出した。

固定ページ5件の内容は、新しいトップページに統合した。静的化では、記事本文を書き出すだけでは足りない。WordPressが暗黙に引き受けていた次の互換性を、すべて静的サイト側で引き継ぐ必要があった。

生成物は、置き場所を示すベースパス（BASE）を切り替えて作れるようにした。テスト用の /takemaru_new/ と、本番用の /takemaru/ である。この設計が、7章の本番用ビルドで効いてくる。

06デザインと「正本」の管理

武丸のデザインコンセプトは「磯釣り専門誌 × 海の迫力」とした。先に作った重五郎屋と似たものにしないことが、明確な条件だった。墨色と濃紺を基調に、朱色を差し色に使い、海・磯・渡船の写真を大きく見せる。

このデザインの制作中に、複数のAIの出力が混在する問題が起きた。ある時点で、手元には次の状態のファイルがそろっていた。

• Claudeが制作した新しいトップページのv1（index.html・top-assets/top.css・top-assets/top.js）
• ChatGPTが、元の写真17枚から高画質の5枚を作り、v1の写真を差し替えた統合ZIP（HTMLは画像の width・height だけを修正）
• Geminiが作ったコード（旧URLを転送するJSを含む）

筆者が下した判断は、「Claude制作のv1を正本とし、ChatGPTの統合ZIPを現在の正本とする。Geminiのコードは不採用」というものだった。そのうえで、Claudeへの指示は次のように明文化された。

- 正本のv1を基準に、必要な部分だけを修正する。HTML・CSS・JSを大きく書き換えない
- 変更した箇所は、ファイル名と内容を一覧にして報告する
- 作業が終わったら、必ずZIPにまとめてダウンロードできる形にする
- アーカイブに関わる変更は、アーカイブとの動作を照合してから報告する

正本ZIPの監査で見つかったもの

Claudeは作業の前に、正本ZIPの中身（5,272ファイル）を機械的に照合した。ファイル数の内訳と、写真の実寸とHTMLの width・height の一致は確認できた。そのうえで、次の4点が見つかった。

4は、デザインを確定扱いとしていたため修正せずに報告だけを行い、判断は筆者に委ねた。

07本番用ビルドと検証

テスト用の生成物は、すべての絶対パスが /takemaru_new を指している。本番用に変換するには、これを /takemaru に置き換えればよい。その前に、置換して問題がないかを確かめた。

"takemaru_new" の出現数      : 245,102
"/takemaru_new" の出現数     : 242,455
"https://nakagi.net/takemaru_new" : 2,647
→ 242,455 + 2,647 = 245,102（すべてスラッシュ付きのパスとして出現）

すべての出現がパスとして使われていることを確認してから、置換した。結果は5,257ファイル、245,101か所。数が1つ合わないのは、本番用ビルドから除外した robots-preview-note.txt の中の1か所である。

.htaccess には、次の3点の変更を加えた。

1. 転送ルールの /takemaru_new/ を /takemaru/ に置換
2. テスト用に入れていた Header always set X-Robots-Tag "noindex, nofollow" を削除
3. 旧画像を /takemaru_wp/ から配信する3行を追加（11章）

# 武丸 釣果アーカイブ  本番用（BASE=/takemaru）
AddDefaultCharset UTF-8
DirectoryIndex index.html
Options -Indexes
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /takemaru/
# 旧WordPressの画像：/takemaru_wp/ へ退避した uploads を同じURLで配信（URLは変えない）
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^wp-content/uploads/(.*)$ /takemaru_wp/wp-content/uploads/$1 [L]
RewriteRule ^welcome/?$ /takemaru/#greeting [R=301,NE,L]
RewriteRule ^services/?$ /takemaru/#service [R=301,NE,L]

旧WordPressのクエリ形式のURLは、.htaccess ではなくトップページのJSで転送することにした。1,326件分の RewriteCond %{QUERY_STRING} を並べると、.htaccess が肥大化するためである。

// 旧WordPressのクエリURL（?p= ?attachment_id= ?s=）を静的ページへ転送
(function () {
  'use strict';
  if (!window.URLSearchParams) return;
  var q = new URLSearchParams(location.search);
  var dir = location.pathname.replace(/[^\/]*$/, '');   // 例：/takemaru/
  var base = dir.replace(/\/$/, '');
  if (q.has('s')) { location.replace(dir + 'search/?q=' + encodeURIComponent(q.get('s'))); return; }
  var p = q.get('p'), a = q.get('attachment_id'), id, keys;
  if (/^\d+$/.test(p || '')) { id = p; keys = ['p', 'a']; }
  else if (/^\d+$/.test(a || '')) { id = a; keys = ['a', 'p']; }
  else return;
  fetch(dir + 'archive-assets/idmap.json').then(function (r) { return r.json(); }).then(function (m) {
    for (var i = 0; i < keys.length; i++) {
      var u = m[keys[i]] && m[keys[i]][id];
      if (u) { location.replace(base + encodeURI(u)); return; }
    }
  }).catch(function () {});
})();

Apacheで本番の構成を再現して検証

Claudeの作業環境にApache 2.4を入れ、/takemaru/（新しいサイト）と /takemaru_wp/（旧WordPress。.htaccess と参照画像のダミー6,829件だけ）を並べて、本番の切り替え後の状態を再現した。

画像の存在確認には、鍵による認証を付けた確認用PHPを別のフォルダで用意した。このPHPは読み取り専用で、鍵がない場合は404を返す。参照画像6,829件の存在とサイズが0バイトでないことを調べるほか、manifest.tsv（5,270ファイルのパスとサイズ）と照合して、アップロード漏れやサイズの違いを検出する。リスト類（.txt・.tsv）は .htaccess で外部から読めないようにした。

085,270ファイルをどう運ぶか

テスト公開では、ZIPを転送し、サーバー上でPHPを使って展開する方式を使った。この展開用PHPにはChatGPTがコードレビューを行い、次の不足が指摘されて修正している。

• 第三者がURLにアクセスして実行できないよう、認証を追加する
• ZIP内の全エントリーを展開前に検査し、../、絶対パス、想定外のフォルダ、シンボリックリンクなどを拒否する
• 展開先を takemaru_new/ 以下に限定する
• 展開前に、ZIPの展開後の総サイズとサーバーの空き容量を確認する
• 失敗した場合はPHPを自動削除せず、原因を確認できるようにする

本番への移行では、Claudeの手順書はFFFTPによるフォルダごとのアップロードを案内していた。展開用PHPを公開領域に置かずに済むためである。しかし実際には、大量の個別転送の途中でアップロードエラーが起きた。そこで個別の転送を中止し、ZIPを一括で展開する方式に切り替えた。本番用に展開されたファイルは5,270件である。

09Meta Graph APIとの格闘

武丸では、奥さんがInstagramに投稿すると、Facebookページにも自動で共有される運用がすでにできあがっていた。目標は、この投稿の流れを一切変えずに、ホームページを3つめの表示先として加えることだった。

奥さんがInstagramへ投稿
       │
       ├── Facebookページへ自動共有（Metaの標準機能）
       │
       └── Instagram Graph API
                 │
                 ▼
          さくらサーバー（PHP＋CRON）
                 │
                 ▼
          武丸ホームページ

設計段階の想定と、実際にたどった道

設計段階でClaudeが推奨していたのは、Facebookページを経由しない「Instagram API with Instagram Login」型だった（接続先 graph.instagram.com、権限は instagram_business_basic のみ、60日間有効の長期トークンを refresh_access_token で自動更新する）。Facebook Login型は「Facebook側の状態に左右される」として、不採用にしていた。

実際には、まったく逆の経路で開通することになった。

管理単位の迷路

Meta for Developersで、アプリ Takemaru Catch Feed を作成した。しかしMetaの開発環境には、次の管理単位が重なっている。

• 個人のFacebookアカウント
• Meta開発者アカウント
• ビジネスポートフォリオ
• Facebookページ
• Instagramプロアカウント
• 開発アプリ
• アプリに付与するアクセス許可

武丸のビジネスポートフォリオは、奥さんが管理していた。筆者は自分のFacebookアカウントを、そのポートフォリオに招待してもらった。しかし、招待されただけでは開発アプリとの関連付けはすぐには完了しなかった。さらに、Metaの新しいUnified Login側では既存のビジネスポートフォリオを選択できず、新しいポートフォリオを作る画面へ進んでしまった。

API権限と実データ

Graph API Explorerで使った権限は次の3つで、Facebookログインの認証画面で、対象のFacebookページとInstagramアカウントだけを選んだ。

instagram_basic
pages_show_list
pages_read_engagement

Facebook Page ID:              2095641747334370
Instagram Business Account ID: 17841406985745841

まず、FacebookページとInstagramアカウントが紐付いていることを直接確認した。

GET /2095641747334370
    ?fields=id,name,instagram_business_account

GET /17841406985745841/media
    ?fields=id,caption,media_type,media_url,permalink,timestamp
    &limit=3

ここで、投稿ID、本文、写真URL、投稿へのリンク、日時が返ってきた。

トークンの寿命

Graph API Explorerが最初に発行したのは、短期のUser Access Tokenだった。その後、Page Access Tokenも取得できたが、有効期限は約1時間しかなく、CRONでの長期運用には使えない。そこでAccess Token Debuggerを使い、次の順序で確認を進めた。

1. 短期のUser Tokenを確認する
2. User Tokenを延長する
3. 長期のUser Tokenを発行する（Debugger上の有効期限：2027年1月4日）
4. 長期のUser TokenからPage Tokenを取得する
5. そのPage Tokenで、Instagramの投稿取得を再試験する
6. Debuggerでトークンの種類と有効期限を確認する → 有効期限「なし」

10fetch.php――毎時23分のパイプライン

/home/hirizo/
├── ig_takemaru/          ← DocumentRootの外
│   ├── config.php        ← トークン（権限600）
│   ├── fetch.php
│   ├── fetch.log
│   └── fetch.lock
└── www/
    ├── takemaru/
    └── takemaru_data/
        ├── ig.json
        └── ig/            ← 保存した写真

config.php.php 事件

最初の設置で、Windows側の拡張子の扱いを誤り、config.php.php という名前でアップロードされた。FFFTPの一覧で気づき、config.php に直している。小さなミスだが、設定ファイルを require する構造では、これだけで全体が動かなくなる。

fetch.phpの設計

ChatGPTとの作業で作られた fetch.php の要点を、実ファイルから抜粋する（トークンは config.php から読み込むため、ここには含まれない）。

<?php
/** 武丸 Instagram read-only synchronizer; PHP 7.4+, CLI only. */
if (PHP_SAPI !== 'cli') { http_response_code(403); exit; }

try {
    // Auth only to Graph API, via request header (not logged in URLs).
    $endpoint = 'https://graph.facebook.com/v27.0/' . $igId . '/media?fields=id,caption,media_type,media_url,thumbnail_url,permalink,timestamp&limit=12';
    $ch = curl_init($endpoint);
    $body = '';
    curl_setopt_array($ch, [CURLOPT_RETURNTRANSFER=>false, CURLOPT_FOLLOWLOCATION=>false, CURLOPT_CONNECTTIMEOUT=>12, CURLOPT_TIMEOUT=>40,
      CURLOPT_SSL_VERIFYPEER=>true, CURLOPT_SSL_VERIFYHOST=>2, CURLOPT_HTTPHEADER=>['Authorization: Bearer '.$cfg['page_token']],

このほかに、画像の取得先を cdninstagram.com・fbcdn.net に限定し、リダイレクトを追わず、受け取るサイズに上限を設けている。写真はGDで長辺1600pxに縮小し、JPEG品質85で保存する。

        // Preserve aspect ratio, cap longest side at 1600 px
        $scale = min(1,1600/max($w,$h));
        $res = imagecreatetruecolor(max(1,(int)round($w*$scale)),max(1,(int)round($h*$scale)));
        $white = imagecolorallocate($res,255,255,255); imagefill($res,0,0,$white);

    if (!$items) throw new RuntimeException('No valid posts; existing feed preserved');
    usort($items, function($a,$b){return strcmp($b['timestamp'],$a['timestamp']);});
    $json=json_encode(['items'=>$items],JSON_PRETTY_PRINT|JSON_UNESCAPED_UNICODE|JSON_UNESCAPED_SLASHES|JSON_INVALID_UTF8_SUBSTITUTE);
    if ($json===false) throw new RuntimeException('JSON encode failed');
    save_atomic($outRoot.'/ig.json',$json);
    echo 'OK: '.count($items)." posts saved\n";

「ログが0バイト」をどう読むか

/usr/local/bin/php /home/hirizo/ig_takemaru/fetch.php >> /home/hirizo/ig_takemaru/fetch.log 2>&1

2026年11月5日23時23分の初回実行の後、fetch.log と fetch.lock ができていた。ただし fetch.log は0バイトだった。その時点では成功と断定せず、出力のほうを順に確かめた。

/home/hirizo/www/takemaru_data/ig.json   8,242 bytes
/home/hirizo/www/takemaru_data/ig/       12 files

最後にトップページで実際の釣果が表示されることを確認し、Graph API → PHP → 画像保存 → JSON生成 → JavaScriptで描画 という一連の流れが動いていることを検証した。

11本番切り替え――名前を2回変えるだけ

本番への移行では、旧WordPressを削除も移動もせず、フォルダ名の変更だけで切り替えた。

変更前：
www/
├── takemaru/       ← 旧WordPress（公開中）
├── takemaru_new/   ← テスト用
└── takemaru_next/  ← 本番用（BASE=/takemaru でビルド）

変更後：
www/
├── takemaru/       ← 新しい静的サイト
├── takemaru_wp/    ← 旧WordPress（そのまま保管）
└── takemaru_new/   ← テスト用

takemaru      → takemaru_wp
takemaru_next → takemaru

元に戻すときは、名前を逆の順に変えるだけでよい。旧WordPressの .htaccess、wp-config.php、データベースには、切り替えの間も一切触れていない。

6,829件の画像参照を守る

過去記事のHTMLには、旧WordPressの画像パス /takemaru/wp-content/uploads/YYYY/MM/... がそのまま残っている。WordPressを takemaru_wp に移すと、画像の実体もそちらへ移る。HTMLを大量に書き換える方法も、画像をコピーする方法も取らなかった。新しい /takemaru/.htaccess に、7章で示した3行を加えただけである。

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^wp-content/uploads/(.*)$ /takemaru_wp/wp-content/uploads/$1 [L]

このリライトは内部で処理されるため、ブラウザから見えるURLは変わらない。リライト後のリクエストは /takemaru_wp/ 側の .htaccess（WordPressの標準ルール）でも処理されるが、実在するファイルに対しては条件 !-f が成立しないため、そのまま配信される。この方式なら、/j568/ など他のサイトが武丸の画像を参照していても、同じURLのまま表示される。

画像参照            ：6,829件
見つかった画像      ：6,829件
見つからない画像    ：0件
0バイトの画像       ：0件

本番用ファイル      ：5,270件
不一致              ：0件
.htaccessの検査     ：OK

12公開後の3つの改修

公開後すぐに、3つの改修を依頼した。いずれも、完成したデザインを維持したまま機能だけを足すことが条件だった。

月ごとの出船時間を自動で表示する

要件は「日本時間を基準にし、閲覧者の端末のタイムゾーンに左右されない」「JavaScriptが無効でも、誤った時刻を表示し続けない」の2つ。Claudeは Intl を使わず、日本に夏時間がないことを利用して、UTCに9時間（324e5 ミリ秒）を足す計算にした。時刻のデータはHTMLの属性に持たせ、要点欄の直後に置いたインラインスクリプトで書き換えている。

<div><dt>出船</dt><dd data-dep="6:30,6:30,6:00,6:00,6:00,5:30,5:00,5:00,5:30,6:00,6:30,6:30"><b>月別</b><small><a href="#service">5:00〜6:30（月ごとの出船時間）</a></small></dd></div>

<script>/* 出船時間：日本時間の月で表示（JS無効時は月別の案内のまま） */(function(){var d=document.querySelector('[data-dep]');if(!d)return;var t=d.getAttribute('data-dep').split(','),m=new Date(Date.now()+324e5).getUTCMonth();if(t.length!==12||!/^\d{1,2}:\d{2}$/.test(t[m]))return;d.querySelector('b').textContent=t[m];d.querySelector('small').textContent=(m+1)+'月の出船時間';})();</script>

検証では、ブラウザのタイムゾーンをロサンゼルスに設定し、日本時間での月の変わり目を含む6つの時点で表示を確かめた。たとえば日本時間の2月28日23時59分は「6:30／2月」、3月1日0時0分は「6:00／3月」と表示される。

Googleマップを自動で表示する

それまでの地図は、表示速度とプライバシーを優先して「タップすると読み込む」方式だった。これを、地図の600px手前までスクロールした時点で、IntersectionObserverでiframeを差し込む方式に変えた。プレースホルダーは <button> からGoogleマップへのリンク（<a>）に変えたので、JSが無効な場合や、30秒以内に読み込みが終わらない場合でも地図を開ける。

    if ('IntersectionObserver' in window) {
      var mo = new IntersectionObserver(function (es) {
        for (var i = 0; i < es.length; i++) if (es[i].isIntersecting) { mo.disconnect(); loadMap(); return; }
      }, { rootMargin: '600px 0px' });
      mo.observe(map);
    } else loadMap();
  }

Instagram釣果のページ送り――なぜ9件と12件なのか

依頼は「1ページ12件程度」だった。しかし、既存の最新釣果グリッドには、先頭の1枚を大きく見せる設計がある。グリッドが何マスを使うかは、画面の幅によって変わる。

3つの条件を同時に満たす件数は、n ≡ 9（mod 12）、つまり9件、21件、33件……である。12件にすると、PCでは最後の行に1マス、スマホでも1マスの空きが出る。元の設定の9件は、この3つの条件を同時に満たす最小の数だった。

ページ番号はURLに ?igp=N として残す。history.pushState と popstate を使い、ブラウザの戻る・進む、再読み込み、範囲外の数字、不正な値でも破綻しないことを確認した。ボタンの高さは44pxで、375px以上の幅では1行に収まる。

この改修の途中で、別の不具合も見つかった。投稿日の表示が、APIの返すUTCの日付をそのまま使っていたのである。日本時間で午前9時より前の投稿は、前日の日付で表示されていた。これも日本時間で表示するように直した。

13archive.php――過去を少しずつ遡る

最新の釣果がトップに出るようになっても、それだけでは不十分だった。過去1,326件のWordPress記事を静的化して残したのに、Instagramに移ってからの釣果は、最新の12件より前が見られない。釣果の記録が途中で途切れてしまう。

fetch.php（毎時23分）  … 最新12件を取得 → ig.json（変更なし）
archive.php（毎時33分）… ① ig.json を取り込む（APIは使わない）
                          ② 過去分をAPIのページ送りで遡る（完了するまで）
                          ③ ページ単位の公開用JSONを作る

取り込みと遡り

新しい投稿は、fetch.php が書き出した ig.json から取り込む。写真のファイル名 /takemaru_data/ig/{投稿ID}.jpg から投稿IDを取り出し、それをキーにして archive.json（公開領域の外）に追加・更新する。削除はしない。

    // 1) ig.json（fetch.php の成果）を取り込む。APIは使わない
    $feed = @json_decode((string)@file_get_contents(IGA_WWW_DATA . '/ig.json'), true);
    $fromFeed = 0;

過去分は、Graph APIの /{IG-ID}/media を after カーソルで遡る。進んだ位置は archive_state.json に、1ページ処理するごとに保存する。レスポンスの paging.next にはトークンを含むURLが入ることがあるため、これは使わず、カーソルだけを使って自前でURLを組み立てる。

        while (empty($state['done']) && $pages < IGA_PAGES_PER_RUN && (time() - $t0) < IGA_MAX_SECONDS) {
            $q = IGA_IG_ID . '/media?fields=' . rawurlencode($fields) . '&limit=' . IGA_API_LIMIT;
            if (!empty($state['after'])) $q .= '&after=' . rawurlencode($state['after']);

define('IGA_PER_FIRST', 9);      // 1ページ目の件数（トップの大きな1枚つきグリッド）
define('IGA_PER_PAGE', 12);      // 2ページ目以降の件数
define('IGA_API_LIMIT', 25);     // APIの1回あたりの件数
define('IGA_PAGES_PER_RUN', 4);  // 1回の実行で遡るAPIページ数（最大100件）
define('IGA_MAX_SECONDS', 240);  // 1回の実行で過去分の取得に使う最大秒数
define('IGA_RETRY_MAX', 3);      // 再試行の上限回数
define('IGA_KEEP_VERSIONS', 3);  // 公開用の版をいくつ残すか（現行を含む）

公開用JSONを壊さずに差し替える

ページを移動中の閲覧者が、新しい index.json と古いページのファイルを組み合わせて読んでしまうと、表示が崩れる。これを防ぐため、毎回新しい版のフォルダ（v年月日時分秒）に全ページを書き出し、最後に目次の index.json を差し替える。古い版は3つまで残す。内容に変化がなければ、何も書き出さない。

        do { $ver = 'v' . date('YmdHis'); $vdir = $pubDir . '/' . $ver; if (is_dir($vdir)) sleep(1); } while (is_dir($vdir));
        if (!mkdir($vdir, 0755)) throw new RuntimeException('Cannot create ' . $ver);
        $chunks = array(array_slice($pub, 0, IGA_PER_FIRST));
        for ($i = IGA_PER_FIRST; $i < $total; $i += IGA_PER_PAGE) $chunks[] = array_slice($pub, $i, IGA_PER_PAGE);
        foreach ($chunks as $i => $c) save_atomic($vdir . '/p' . ($i + 1) . '.json', json_out(array('page' => $i + 1, 'items' => $c)));
        save_atomic($pubDir . '/index.json', json_out(array('ver' => $ver, 'total' => $total, 'pages' => count($chunks),

/home/hirizo/www/takemaru_data/ig_archive/
├── index.json            ← {"ver":"v…","total":…,"pages":…,"per_first":9,"per_page":12}
├── v20261106…/p1.json, p2.json, …
└── （古い版を最大2つ残す）

模擬APIでの検証

本物のAPIには作業環境から接続できないため、Pythonで模擬のGraph APIを作り、140件の投稿を用意した。このデータには、動画、media_url のない複数枚の投稿、画像のない動画、一覧のURLでは画像の取得に失敗する投稿を混ぜている。

本番での初回

本番での初回実行では、100件の蓄積と、全9ページの表示が確認された。ブラウザで2ページ目に移動し、過去の写真と本文が表示されることも確認している。

14二つのAIと人間

この分担は固定されたものではなく、ファイルの統合やコードの検証など、担当が重なる場面も多かった。

AI同士は、状態を自動では共有しない

開発の途中で、Claudeは「Instagram連携はまだ実装されていない」という前提で作業計画を出していた。正本ZIPの材料チェックに答えた際、作業の順序の最後にこう書いている。

| 7 Instagram API連携 | 後回しにできる | 依頼者側でのトークン発行が先に必要 |

しかし、その時点でChatGPT側では、Metaの認証、PHP、CRON、写真の保存、トップページでの表示まで、すでに成功していた。AI同士は作業の状態を自動では共有しないため、Claudeは手元の資料にある古い状態を前提にしていた。この食い違いは、ChatGPT側の成果をまとめた次の引き継ぎ資料で訂正された。

逆の方向の誤りもあり得た。AIが作業途中の古いZIPを正本と思い込んだり、別の版のファイルを前提に修正を進めたりする危険である。これに対する備えとして、差分を反映する手順には必ず「サーバー上のファイルのサイズが想定どおりか」を確認する手順を最初に入れた。序章の110バイトの食い違いが見つかったのも、この確認の過程だった。

人間に残った仕事

AIにすべてを任せたわけではない。新しいビジネスポートフォリオを作らなかった判断、Geminiのコードを捨てた判断、正本を決めた判断、公開のタイミング、そして実機での確認は、すべて人間が行った。AIの提案が実際の状況と食い違ったときに、それを指摘して直させたのも人間である。今回の開発は、AIが単独でサイトを完成させた事例ではない。AIが制作と分析を担当し、人間が環境と現実の状態を管理した共同開発だった。

15完成時点の構成と残された課題

Instagram（takemaru.nakagi）
     │
     ├── Metaの標準機能 ──→ Facebookページ
     │
     └── Instagram Graph API（graph.facebook.com/v27.0）
               │
               ▼
/home/hirizo/ig_takemaru/          ← DocumentRootの外
     ├── config.php      認証情報（権限600）
     ├── fetch.php       毎時23分：最新12件
     ├── archive.php     毎時33分：取り込み・遡り・公開
     ├── archive.json    全投稿の保存データ
     └── archive_state.json
               │
               ▼
/home/hirizo/www/takemaru_data/
     ├── ig.json
     ├── ig/{投稿ID}.jpg
     └── ig_archive/index.json, v…/p{N}.json
               │
               ▼
/home/hirizo/www/takemaru/
     ├── index.html, top-assets/
     ├── 過去記事HTML（1,326件）, archive-assets/, search/
     └── .htaccess（転送229件＋uploadsの内部リライト）
               │
               ▼
閲覧者のブラウザ

/home/hirizo/www/takemaru_wp/      旧WordPress（画像の配信元として稼働中）

終レガシー環境を壊さず再構築するという仕事

2つのサイトに共通するのは、最新の技術に置き換えること自体を目的にしなかった点である。重五郎屋ではAmebloを、武丸ではInstagramを投稿元にした。どちらも公開側は静的HTMLとし、外部サービスとの接続をPHPとCRONに任せた。毎日投稿する人は使い慣れたサービスをそのまま使い続け、公開サイトは独自のデザインを持ち、過去の情報を保ち、将来も拡張できる。

AIの出力は、いつも正しかったわけではない。古いファイルを前提にしたことも、権限の仕組みを読み違えたことも、完了済みの工程を未完了だと思い込んだこともあった。設計段階で推奨したAPIとは逆の経路で開通し、手順書で案内した転送方法は途中で失敗した。それでも、実際のサーバーの状態を確かめ、問題を小さく切り分け、一つずつ直していくことで、システムは完成した。

設計と実装は、AIで大幅に速くできる。しかし、現実のシステムを理解し、壊さずに運用する責任は、人間に残る。

記録：2026年11月6日時点／対象：nakagi.net/j568/、nakagi.net/takemaru/／本文中のコードは、納品したファイルと受け取ったファイルから機械的に抜粋した（本番サーバー上のファイルとの照合は、手順書のサイズ確認による）。トークン、パスワード、確認用PHPの鍵は掲載していない。