GitHub Actionsで更新されてるが最終更新が5ヶ月前だな、なぜだろう

原因はこれです：

このリポジトリは自前のActionsではなく、別リポジトリ nishio/from_scrapbox のワークフローが毎日スクラップボックスをエクスポートしてここにプッシュする設計。Scrapbox側のメモにもそう書かれています。 (現状の英訳外部脳もGitHubにいれる)

その from_scrapbox のワークフローは cron（JST 5:00）で毎日走る設定ですが、GitHubの仕様で「リポジトリ活動が60日間ないと定期実行ワークフローは自動で無効化」されます。実際、from_scrapbox の Actions 画面は現在 “Disabled” になっています。 (GitHub)

えっ、そうなんだ、知らなかった

実際の履歴も合致していて、目的のリポジトリは 2025-06-23 の自動コミットを最後に止まっています（ちょうど from_scrapbox の最終コミット 2025-04-24 の約60日後）。 (GitHub)

直す手順（最短）

1. nishio/from_scrapbox → Actions → 各ワークフローを Enable。その後 Run workflow で手動実行。 (GitHub)

2. 動き出したら、再発防止として次のどれかを入れておく：

ワークフローの最後に from_scrapbox 自身に “heartbeat” ファイルへ日付を書き込むコミットを入れて、60日無活動を回避（活動＝コミット）。仕組み自体はGitHub公式の60日ルールに起因します。 (GitHub Docs)

あるいは Dependabot などで月1回はPR（=活動）を発生させる。 (Zenn)

設計を見直し、スケジュール実行を external_brain_in_markdown 側に移す（自分にコミットするので活動が維持されやすい）。

※ もし動かない場合は、from_scrapbox のワークフローが使っている PAT/SID シークレットの失効も併発しがちなので、合わせて確認を。ワークフロー内で PAT を使って他リポジトリに push している記述あり。 (GitHub)

必要なら、“heartbeat” の最小パッチ案もすぐ書きます。

以前mem.nhiro.orgなるものを対外的なScrapboxのビューとして作ったと思うんだけど、それの改善を進めていきたい

いいですね。ざっと現状を押さえたうえで、mem.nhiro.org 改善の即効プランを短くまとめます。

まず把握（前提）

mem は yuta0801/scrapbox-reader のフォークで、Scrapbox APIから取得→静的配信（Vercel）という構成。READMEにもそう書かれています。(GitHub)

過去メモでは「parserが古い」「タイトルのエンコードがやや不正確」「TweetボタンのURL更新問題」等が指摘済み。(*1 /villagepump/mem.nhiro.org:done~2022-03-08)

今日から入れられる“最小の勝ち”3点

1. parser更新＋タイトルエンコード修正（品質）

@progfay/scrapbox-parser を最新版へ。Scrapbox構文の追従性と安定度が上がります。(GitHub)

タイトルの正規化は、過去指摘（ generate_links.tsx ）の方針に合わせて修正。絵文字・結合文字で split("") を避ける実装が必要。(*1)

2. “pXXXX”系の索引ページ（情報動線）

p.* で始まるページを月別/年別に自動リストし、日々の記録へワンクリック導線を追加。

取得は Scrapbox API の search/titles または search/query を利用（静的生成 or ISR）。(Cosense)

3. 関連記事（バックリンク）サイドカード（発見性）

ページJSONの links から相互リンク/片方向リンクを集計し、本文右にカード表示。まずは内部リンクのみで十分。(Cosense)

配信と保守の軽量強化（次点）

更新の自動新鮮化：Vercel Cron で毎日 revalidate（ISR）し、API変更や一時的失敗時の外部脳Markdownリポジトリをフォールバック（読み取り専用）。構成はそのまま、信頼性だけ底上げ。(GitHub)

OGPの安定生成：NextのOG Imageを自動生成（1行目＋先頭画像）。過去にTwitter Card導入済みの文脈を、静的/ISRで確実化。(Cosense)

この順でいけば、見た目は変えすぎずに“迷子率”と“表示の破綻”を先に潰せます。

着手順に迷うなら、今日は ①parser＋エンコード修正 → ②p索引 → ③関連記事 の順がおすすめです。

---

repo:

---

英語で配信してる？

短く言うと「部分的に英語」。

サイト全体は中身は主に日本語とトップで明記。ただし英語の案内とリンクはある。 (mem.nhiro.org)

本の英訳 “Engineer’s way of creating knowledge” は mem.nhiro.org 上で英語配信。 (mem.nhiro.org)

日々のメモは /nishio-en（Scrapbox側）でDeepL自動翻訳の英語版を別プロジェクトとして公開。 (mem.nhiro.org)

mem のREADMEも「機械翻訳に相性が良い」設計と書いてあるが、サイト全体のi18n切替は未導入。 (GitHub)

必要なら、/en ルートで nishio-en を同じビューで出す（言語トグル追加）という実装案、すぐ出せます。

---

そうか、エンジニアの知的生産術の英語版を作ってそれを配信したのか

---

現状のnishio-enは行単位DeepLで翻訳の品質が低い

OpenAI APIの性能が上がったためページ全体のより良い翻訳が可能だと感じている

一方で単なる翻訳ではなくもっと有益なき知的生産の苗床になるようにできないかという気持ちと

そもそも事前に英訳する必要などないページが結構たくさんあるよなという気持ちもあり

いい方法に悩んでいる

いいテーマですね。結論から：

方針（ぜんぶ訳さない・“苗床化”を優先）

三段階に分ける

L0: 非翻訳（そのまま日本語。p日次系など）

L1: 英語サマリー（3文要約＋キーワード＋関連リンク）

L2: 完全訳＋注釈（背景説明・外部読者向け補足・用語集を同梱）

起動条件

L2は「公開価値が高い/外部から参照される」ページだけ。

それ以外はまずL1で“苗床”に（英語の入口＝気づき→議論→磨く）。

設計（JIT翻訳＋キャッシュ、用語メモリ）

JIT生成 → 永続キャッシュ

初回アクセス時に翻訳/サマリーを生成→保存（ISR/DB/GitHub）→再利用。

事前一括翻訳はしない（無駄を削減）。

構造化出力で一発整形

OpenAI Responses APIを使い、JSON Schemaで

{abstract, key_terms[], full_translation?, notes[], link_map} を厳密生成。 (OpenAI Platform)

用語集・スタイル

glossary.json をGitで管理し、プロンプトに毎回注入。

（必要なら）関数呼び出し/ツール呼び出しで「用語未登録」を自動検出→PR化。 (OpenAI Platform)

価値追加（“翻訳以上”の苗床要素）

ページ先頭に 「For international readers」 カード：

1. 3文サマリー（L1） 2) 用語5個 3) Open Questions（2–3点） 4) 関連ページ

リンク書き換え：日本語ソースしか無い場合は代替英語文献を自動検索→補助リンク欄へ（手動承認）。

月次ハーベスト：p日次を英語ダイジェスト（Top 5トピック＋引用）に束ねて公開。

最小実装（Next.js想定）

1. /en/[project]/[title] で表示

2. 取得：Scrapbox JSON → 前処理（見出し・リンク抽出）

3. Responses APIへ投入（モデルは速度/コストで2段：Draft=軽量、Publish=高品質）

4. 返却JSONをレンダリング→ISRでキャッシュ（手動Publish時だけ再生成）

API要点：Chat CompletionsよりResponses APIが推奨、Structured OutputsでJSON強制。 (OpenAI Platform)

モデル運用の勘所

Draft↔Publishの二段

Draft: 軽量モデルで即時（下書き品質）

Publish: 高性能モデルで仕上げ（用語整合・注釈）

評価：固定サンプル10ページで、可読性/忠実度/用語整合をAB記録。

コスト管理：人気ページのみ自動再生成（更新検知）／低PVはリクエスト時のみ生成。

タグ運用（Scrapbox側）

en:skip … L0固定

en:summary … L1固定

en:publish … L2候補（審査用キューに入れる）

glossary:用語 … 用語抽出の手掛かり

必要なら、Responses API + Structured OutputsのTS最小スニペット（JSON Schema込み）を出します。これで「訳すべきものだけ良く訳し、それ以外は“英語の入口”に止める」運用へ、今日から移れます。

データの置き場所やデプロイ先に関する考察を先にしてほしい

真のソース：Scrapbox（tag:catalog を付けたページ群）

派生データ＆キャッシュ：GitHub専用リポ nishio/mem-data に JSON で保存

例）catalog/index.json、translations/<pageId>.json、glossary.json

配信：既存の Vercel（Next.js） を継続

ISR（Incremental Static Regeneration）で mem-data を取り込み

翻訳の JIT生成→mem-data へコミット → 対象ページを revalidate

この構成だと「設定不要・可視性高い・ロールバック簡単」で、DB を増やさず **GitHub を“記録＆審査可能なデータ層”**にできます。

いま https://github.com/nishio/from_scrapbox が https://github.com/nishio/external_brain_in_markdown にデータを書いている

了解。その前提なら、**外部脳（external_brain_in_markdown）を“唯一のデータ置き場”**にするのが最小変更で速いです。

色々なリポジトリに情報が散っているので、external_brain_managementみたいなrepoを作ってgit submoduleで関連したrepoを全部子要素にすると言うのはどう？

あり。“管理用メタリポジトリ＋git submodule” は、散らばった外部脳系リポを一箇所から見渡して操作するのに向いてます。ただし**“制御盤”用途に限る**のがコツ（そこ自体で本番ビルドしない）。

next