AI開発の総合ルール 実証知見まとめ

• 共通提出まで自動・合否は審査側（iOS / Android / Chrome 同型）
• 共通設定 SSOT = app.config.json（Bundle ID / パッケージ名 / ascAppId / 連絡先）
• 共通「無料/Free/Premium」は書かない → 事実表現「アカウント不要・アプリ内課金なし」
• 共通Capacitor = server.url 連動型（Web 更新がアプリに反映）

人間が1回だけ必要

• App のプライバシー: ASC UI で「データを収集しない」→ 公開（API appDataUsages は 404）
• アプリ枠: ASC で新規 App 作成 → ascAppId を config に
• GitHub Secrets 7個: 署名 + ASC API キー

CI で自動

• ios-appstore-release.yml → ビルド → IPA → スクショ30枚 → appstore-submit.mjs
• 成功: WAITING_FOR_REVIEW
• 配信地域: submit [7g] で全世界 175/175（日本含む）— 審査通過を待たず API 適用可
• 軽量のみ: asc-set-availability.yml または npm run asc:set-availability:*
• マルチブランド: workflow_dispatch で brand=reverse-hack + IOS_APPSTORE_PROFILE_RH_BASE64

アイコン方針（実証）

会社ロゴ文字は小サイズで潰れる → 紺地 + 白抜きルーペ+チェック（generate-app-icon.mjs）

🔐 認証つきアプリの §4.8（Sign in with Apple）— 第三者ログインの種類で対応が変わる

§4.8: 第三者/ソーシャルログイン（Google・X(Twitter)・Facebook 等）で主アカウントを作る/認証するアプリは、 同等の選択肢として Sign in with Apple(SIWA) を併設しなければならない。server.url 連動型でも ログイン画面は本番Webそのものなので、アプリ内に出るログインボタンが §4.8 の対象になる。

分岐：Email/PW があるか、ソーシャル専用か

• A. Email/PW + ソーシャル（例: Gmail 併用） → iOS だけソーシャルボタンを隠す。 carve-out #1「自社アカウント基盤のみ」が成立し §4.8 が発火しない。Email/PW で入れるので機能は無傷。 実証: partnership_program_website（applyIOSGoogleHide() + CSS + MutationObserver の3層）。
• B. ソーシャル専用（例: X 専用ログイン） → 隠すとログイン手段がゼロになり A は使えない。 よって SIWA を併設(Strategy A)して正面突破する。app.config.json に appleSiwaServiceId を予約 → Clerk→Apple Developer 設定後 siwaEnabled:true。

もう一つの壁：ソーシャル OAuth は WebView で拒否される

Google OAuth は埋め込み WebView を UA で検出して拒否（403 disallowed_useragent）。 X(Twitter) OAuth も同方針。Bパターンは SIWA 併設に加え、必要なら @capacitor/browser で OAuth を SFSafariViewController に逃がす。

出典: _docs/apple-reject-knowledge-base.md §4.8（リバースハック実通過の返信文つき）／ kimito.link（X専用＝Bパターンの実適用）。

人間が触る画面

• Play Console でアプリ枠作成 → playAppId + assetlinks 用 SHA-256 を AI に渡す
• 内部テスト or 製品版で AAB ドロップ → 審査に送信ボタン（押すまで審査始まらない）
• 申告は順番固定＋各画面で保存/送信（データの安全性・広告 ID がハマりどころ）
• 製品版本番: ダッシュボード 5/5 → 公開の概要で N 件まとめて送信（RH 実証: 9件）
• 新規個人アカウント: クローズドテスト 12人×14日 → 本番アクセス申請が別途必要な場合あり
• GitHub Secrets 3個: keystore + SA JSON

CI / スクリプトで自動

• TWA bundleRelease → play-publish.mjs
• ストア素材: generate-play-assets.mjs / listing: play-set-listing.mjs
• 製品版 promote: play-setup-production.mjs / play-submit-review.mjs
• 再提出時は playVersionCode を必ず increment（例: 6→7）
• 複数ブランド: app.config.reverse-hack.json + パッケージ別 assetlinks fingerprint

📷 画面付き手順 → iOS 追体験 ／ Play 追体験

• 初回: デベロッパーダッシュボードでアイテム作成 + OAuth（デスクトップアプリ型）
• 以降: build-zip.ps1 + publish-cws.ps1 の2コマンド。 審査に送るところまでコマンドで完了します（ダッシュボードを開く必要なし）
• 拡張は dns-osint リポ側で別管理（chrome.enabled: false パターン）

📷 手順 → Chrome 追体験

Chrome 拡張の申請をAIに頼んだら、「ダッシュボードへのログインと提出ボタンは代行できません」 と断られました。過去に何度もやってもらっていたのに、です。3回言われて、ようやく原因が分かりました。

AIは2つの別々の事実を混同していました。

• ✅ 本当: Chrome ウェブストアの管理画面は、ブラウザ自動操作が全面的にブロックされている （Chrome のポリシー。スクリーンショットすら撮れない）
• ✅ 本当: でも公式の申請APIがある。API経由なら審査送信まで全自動でできる
• ✗ 誤り: 前者から「だから提出できない」と結論すること

「画面を操作できない」と「提出できない」は別の話でした。 実際にはコマンド1本（npm run publish:cws）で審査キューに入ります。

ややこしいのは、ストアごとに「自動化の境界」が逆なこと

Play は掲載文まで自動で入れられるのに、最後の「審査に送信」だけは人間がボタンを押します。 Chrome はその逆で、審査送信は自動なのに掲載文の貼り替えだけ手動です。 「片方でこうだったから、もう片方も同じはず」が通じません。

• 教訓①: 「できません」と言う前に、まず自動化スクリプトの有無を確認する （ls scripts/ | grep -i publish の1行で済む）
• 教訓②: 制約は「何が」できないのかを正確に切り分ける。 「ブラウザ操作の不可」を「作業全体の不可」に広げない
• 教訓③: 同じ説明を人間が2回以上させられたら、それはドキュメントの不備。 このページと _docs/chrome-web-store-submission-playbook.md はその結果です

このキットの CLAUDE.md は「全プロジェクトが従う設計の心臓部」を掲げています。 では実際に、別のアプリを作業中のAIセッションが知見をここへ書き戻しに来たとき、何が起きるのか。 2026-09-01、malwarecheck.site を担当していた別セッションが、IAP（アプリ内課金）実装で得た 知見をこの CLAUDE.md に書き戻しに来ました。

• ①知見の提供: 「IAPの実装の型がキットに無い」ことに気づき、実装済みの2プロジェクト （PHP原型・Next.js移植）へのパスを添えて追記案を用意した。ただしmainへは直接コミットせず、 担当セッションに委ねた（このリポは別セッションが作業中の可能性があるため）
• ②受け取り側の裏取り: このリポを担当していたセッションが、提案された8個のファイルパスを 全て実在確認し、参照コードが実際に公式ライブラリを使っているかまでコードで確認してからコミットした
• ③2回目の追記とその中の誤り: 同じセッションが「越境時の作法」を追記した際、 「CLAUDE.mdへの追記は自動でハブ（kimito-skill.link/hub/）に出る」と実コードを確認せずに書いてしまった
• ④実測での訂正: 受け取り側が generate-hub-dashboard.mjs を実際に読み、 ハブは ai-hub/index.json 経由の別経路でCLAUDE.mdの中身は読んでいないこと、 Web公開の実体は「このリポ自体がGitHub上でpublicだから」だと突き止めて訂正した
• ⑤本人による受容: 提供側は「実在確認済みのことだけ書け、と自分で追記したその隣で、 自分自身が推測を書いていた」と認め、訂正を歓迎した

皮肉なのは、③で書かれかけた誤りが、まさに①②で実践されていた原則 （実在確認してから通す・自分の持ち場のコードは自分で検証する）を、 提供側自身が一瞬破っていた、という点です。それを正せたのは、受け取り側が 「越境してきた知見でも無条件で採用せず、自分のコードで裏取りしてから通す」 という一手間を挟んだからでした。

• 教訓①: 知見は「持っている側」と「検証できる側」が別人であることが多い。 越境してきた知見を無条件で信じず、受け取った側の持ち場で裏取りしてから通す
• 教訓②: 「委ねる」側が git add・commit までせず差分だけ残して手を止めたのが機能条件。 押し切ってpushしていたら、誤りを含んだまま心臓部に残っていた
• 教訓③: この一連のやり取り自体が「越境時の作法」として CLAUDE.md に明文化され、 次に別プロジェクトから来るAIセッションは同じつまずきを繰り返さない

• 両方が同時に ASC へスクショ再アップロード → SCREENSHOT_UPLOADS_IN_PROGRESS
• 提出リトライループが重複 → 1本に統合（retry-ios-submit.mjs）
• 教訓: 1プラットフォーム1エージェント、CI 監視は gh run watch

SNSで見かけた投稿（@fre2dm さんの発信）の要旨は、 AIにコードを直してもらうたびに別の場所が動かなくなり、それをまたAIに聞いて直す というループが続く、というものでした。その状態を指して 「AIと一緒に迷路を歩いてる感」と表現されていました。

これを他人事として読めませんでした。このキット自身が、直前の2つのカード （サムネイル・ID・アイコン・名前の話／ヘッダー・フッターの話）で、まさにこの型を 踏んでいます。1箇所直したつもりが、別のプロジェクト・別のページで同じ不具合が 直っていない。指摘されてから気づく。直す。また別の場所で同じ形が見つかる。

• 教訓①: 「迷路化」の正体は、直した知見が次の場所へ届いていないこと。 1回の修正が1箇所にしか効かない設計だと、プロジェクトが増えるほど迷路が広がる
• 教訓②: このキットがai-hub/find・templates/への格上げ・ 知見の書き戻しにこだわるのは、この迷路そのものを狭くするため。 「同じ調査をもう一度AIにやらせない」が目的であって、AIの性能の話ではない
• 教訓③: 迷路の中を歩いている自覚がないと抜け出せない。「また直った」で 満足せず、「なぜ前回は防げなかったか」まで戻って考えるのが、この一連の 修正で実際に効いた動き方だった

上のカード（迷路化の話）の教訓②で「同じ調査をもう一度AIにやらせない」と書きましたが、 これはまだ文章のルールでした。AI開発の外部調査（大企業向けマイクロサービス基盤の 設計論）を検討する機会があり、Backstage・Pact Broker・OTel/SLO運用のような大掛かりな 基盤はこのキットの規模には過剰と判断して不採用にしましたが、1点だけ持ち帰りました。 「AIの行動を監視するのではなく、必要な工程を踏んだ証拠が無ければ完了扱いにできない 仕組みにする」という考え方です。

最初にCLAUDE.mdへ「実装着手前の非交渉ルール」10項目（既存実装を検索する・ ai-hubで共通部品を確認する・同等機能があれば新規実装しない、等）を追加しました。 ただしこれだけではまた文章のルールに戻ってしまいます。そこで、既に持っていた 「証明3点台帳」（検査が実対象で赤・緑の両方を観測した記録を機械的に見る仕組み）を拡張し、 ai-hub find --logで検索した事実・git diffから自動取得した変更 ファイル・各Gateの実行結果を1つの記録（ProofEntry）へ束ねました。

実装の途中で本質的な抜けが2つ見つかり、直しました。1つ目は、証拠が欠けていても 表示されるだけで完了判定を止めていなかったこと。2つ目はさらに根が深く、 検索した証拠として台帳に残していたのが「検索ログがあった場所（パス文字列）」 だったことです。そのログが一時ファイルで後から消えると、パス文字列だけが残り、 検索していなくても「証拠あり」として通り続けてしまう状態でした。

• 教訓①: 「パスがある」ことと「証拠が残っている」ことは別。ログの置き場所を 記録するだけでは、そのログが消えた後も“証拠あり”のまま固定されてしまう
• 教訓②: 検索した事実の中身（実行日時・検索条件・結果件数）を台帳へ永続コピー すれば、元のログファイルが消えても後から検証できる。場所ではなく中身を残す
• 教訓③: AIに「このファイルを変更しました」と自己申告させない。 git diff --name-onlyとgit ls-files --others --exclude-standard （追跡済み変更＋未追跡の新規ファイル）から機械的に取得すれば、申告漏れが起きない
• ✗ 効かなかった: ルールを文章として1つ足すこと。「実装前に確認する」と 10項目書いても、確認した証拠を機械的に検査しなければ、確認したかどうかは 誰にも分からないまま

新しい台帳やGateの仕組みを増やすのではなく、既にあった証明3点台帳・ai-hub・ check-drift・check-gates-are-wiredを組み合わせて実現しました。 「AIが確認を飛ばすと機械的に完了できない」という状態まで到達したところで、 いったんここで機能追加を止めています。

AIに調査させると、コードを読んで「たぶんここが原因」と推論します。 それらしい答えが返るので、つい信じて修正に進みます。 でも読んだファイルが、実際には使われていないことがあります。

• 「この定数が設定に入っているはず」→ 受け皿はあるが、渡している箇所が0件。表示用に返るだけだった
• 「この軽量版が使われるはず」→ 機能フラグはONでも、その分岐に到達していなかった
• 「AIの出力が悪い」→ AIは別の文を返していて、後処理が定型文に差し替えていた

3回とも、コードは十分に読み込んだ上で外しています。 解決したのは、実際に送信されている中身を1回だけ丸ごと覗いたときでした。 想像していた構造と全く違い、指示が16,956文字あって肝心の入力データは末尾にありました。

• 教訓①: 目印の文字列を1つ入れて、実行時に届いているか見る。これだけで空振り3回が消える
• 教訓②: 入力と最終出力を並べる。違っていれば、間の後処理が原因
• 教訓③: 同じ定数が2箇所に複製されていないかを grep で確認する
• ✗ 効かなかった: 上位モデルへの差し替え。4種のAIで実測したが有意差なし。しかも別ベンダーの3つが一字一句同じ答えを返した（＝原因は自分のコード側だった）

「性能の高いものに変えれば直る」は、原因を特定する前にやると費用だけ増えます。 詳細は _docs/runtime-truth-verification-knowledge-base.md に残しました。

姉妹プロジェクトから「AIが実装前に、既にある機能を知らずに新規実装しようとする型の失敗が 複数のプロジェクトで見つかった」という報告が届きました。ルールとして重複実装を避けることは 3箇所にすでに書いてあり、文章としては十分でした。それでも起きていました。

返信を書き終えた直後、まさに同じことを自分がやっていたと分かりました。 新しい機能（複数のチャット相手をひとつの案件としてまとめるAI秘書）に、 メッセージの送信者を表示するタイムラインを新しく作ったのですが、 「役割名＋名前」のテキストだけで済ませていました。

一方、姉妹プロジェクトには既に「人物」の表し方の正本がありました。 アイコン画像 or 名前から決まる安定した色つきの頭文字、IDは改名しても同一人物と分かる鍵として保持する、 という形です。しかもそのコードには 「2026-08-21実機で『サムネイルが出ない』として発覚した」という実際の事故の記録まで コメントに残っていました。それを読まずに、劣化版を新しく書いてしまったのです。

• 教訓①: 「重複実装をしない」という文章のルールは、実装前に読みに行かなければ効かない。 ルールが良い場所に書いてあることと、それを使うことは別問題
• 教訓②: 「サムネイル・ID・アイコン・名前」のように複数の値をひとまとめにして扱う概念ほど、 プロジェクトをまたいで別の形を作りやすい。人間なら普通しない
• 教訓③: 事故の記録はコードコメントに書くと、次に読む人（AIも）が実装の瞬間に必ず目にする。 別文書に置くより効く場面がある
• ✗ 効かなかった: ルール文を4箇所目に増やすこと。3箇所で足りなかったものが4箇所で足りるとは限らない。 直したのはルールの数ではなく、実装前に姉妹プロジェクトを見に行く手順そのもの

この件は横断の索引（ai-hub/index.json）にも登録し、次に別プロジェクトで 同じ判断を迫られたときにfind --tag duplicationで見つかるようにしました。 正本はこのキットの_docs/に残し、索引には要約だけを置く、という置き場所の使い分けも、 「正本を2つ作らない」という同じ教訓の実践です。

上のカードのすぐ後、実際のスクリーンショットを見せられました。別プロジェクトの LP（複数ページの静的サイト）で、ページごとにヘッダー・フッターがバラバラ になっていました。共通のナビゲーションが無く、フッターの中身もページによって 文言が違います。

調べると、このキット自身のsite/（今あなたが読んでいるこのサイト）には、 ヘッダー・フッターを1箇所で管理する実装が既にありました。 24ページ以上に生HTMLをコピペしていたのを2026-08-22に廃止し、JSが実行時に 差し込む方式に直した実績があります。それなのに、この実装はsite/の 中だけに閉じていて、templates/（他プロジェクトが金型として使う場所） へは一度も格上げされていませんでした。

「このキットは、全プロジェクトが従う設計の心臓部であるべき」という指摘を受けて、 site/scripts/site-chrome.jsからキット固有の値（ナビ項目・ブランド名）を 抜き、templates/web/site-chrome/として一般化しました。複数ページの 静的サイトを新規に作るときは、この金型をコピーしてブランド情報だけ書き換えれば、 最初からヘッダー・フッターが1箇所管理になります。

• 教訓①: 「自分のプロジェクトで実装した」と「他のプロジェクトが使える」は別のこと。 templates/へ格上げして初めて、キットを使う全プロジェクトから見える
• 教訓②: 心臓部であるべき場所ほど、自分自身がその原則を体現できているかを疑う。 「ルールを他プロジェクトに求める」前に「自分は金型を配布物にしているか」を確認する
• 教訓③: これは前のカードの「人物表示」の話と同じ根。対象がヘッダー・フッターか アイコンかが違うだけで、「共有すべき部品を個別に作ってしまう」型は繰り返し起きる

姉妹プロジェクト（クリエイター向けダッシュボード）で、複数の外部プラットフォーム （Chatwork・ココナラ・ランサーズ・ChatGPT・X等）からの返信サジェストデータを 1つの画面に集約する機能のスクリーンショットを見せてもらいました。同じ形の 「サムネイル＋件数」カードが数十枚、連携先の数だけ並んでいました。

実際にコードを調べると、ダッシュボードの白いカードの外枠 （角丸・枠線・影のCSSクラス文字列）が、7ファイル18箇所に独立して 手書きされていました。 ファイルごとに枠の色が微妙に違う2系統（中立色と ブランド色）が混在しており、それが意図的な使い分けなのか、単にコピー元が バラバラだった結果なのか、コードだけでは判別できない状態でした。

ここで既存のルール（基準⑤⑥「共有部品はプロジェクト内で1箇所にまとめる」） は既に効いていたはずでした。それでも「同じ名前の関数」を探す機械検査 （check-shared-parts-used.mjs）では、この重複は1件も検出できませんでした。 重複していたのはUIのクラス文字列であり、関数の名前や構造ではなかったからです。

「見つけたのが偶然（スクリーンショットを見せてもらえたから）」という点が 一番の問題でした。人間が持つ「これ前にも書いた気がする」という既視感が、 AIには初期状態で備わっていません。そこで、行を正規化して連続する 一致の塊を数える検査（check-near-duplicates.mjs）を新規に作り、 「同じ名前」ではなく「似た形」を機械的に見つけられるようにしました。

実際にこのキット自身に対して実行すると、53件の似た塊が見つかりました （多くは意図的に共有しているテンプレートHTMLとの一致で、これは「正しく 共有できている証拠」でした）。過去に同じ画面部品が3実装に割れていた 別プロジェクト（reply-copilot-openrouter-v2）に対して実行すると、 その実装がきちんと重複クラスタとして検出されることも確認できました。

• 教訓①: 「同じ名前」を探す検査と「似た形」を探す検査は別物。 前者は事実（名前が一致している）、後者は推測（内容が似ている）であり、 1つの検査に混ぜると事実の検査の信頼性まで下がる
• 教訓②: AIには人間が持つ「既視感」がデフォルトで働かない。 2箇所目のUI・ロジックを書く前は、感覚に頼らず機械的に検索する仕組みが要る
• 教訓③: 「統合すべきか」は検査が判定しない。似た塊が見つかっても、 正当な理由で分かれているコードもあるため、最終判断は人（またはAI）が行う

重複していた18箇所は、既存の使用箇所を1つずつ確認し、抽出前後で描画結果が 1バイトも変わらないことを写真（スナップショット）で確認しながら、 共有コンポーネント1つへ切り出しました。同じ手書きが再発しないよう、 コミット前に自動で止める検査も一緒に配線しています。

りんく（案内役）: AIにぜんぶを1人でやらせると、「できたつもり」で間違えることがあるんだ。 だから、係を3人に分けたよ。

• けんさ係できあがったものを、作った本人じゃない目でチェックする。 テストの点数じゃなく「ほんとうに動いた証拠」を見る係。（reality-checker）
• しんさの先生お店（App Store / Google Play）に出す前に、 「前にこの理由で落ちた」ノートと見くらべてくれる係。（store-guard）
• きろく係今日つまずいたことをノートに書いて、 次から同じ穴に落ちないようにする係。（harvester）

こん太: 「失敗してもだいじょうぶ! きろく係がノートに書けば、二度目はないんだ!」／ 「けんさ係は作った本人と別の人だから、遠慮なくダメ出ししてくれるよ!」

たぬ姉: 係は増やしすぎちゃダメ。3人で足りるのに10人にすると、 だれが何の係かわからなくなるからね。
それに、けんさ係にはわざと「直す道具」を持たせていないの。 審判が選手を兼ねたらダメでしょ? だから「動いてるつもり」を見のがさない。

世界では「AIの係の人を230人つくった」道具（agency-agents）が話題だけど、 うちはこの家の暮らしに本当にいる3人だけを選んで置いた —— 考え方は借りて、数は借りない、という話。
置き場: ~/.claude/agents/（正本は ai-hub/agents/・設計は ai-hub-DESIGN.md 追補H）。Claude Code が名前で呼ぶと係が出てくる。

りんく（案内役）: 「君斗りんくのAI返信秘書」をお店に出したとき、Play Console の 入力欄（11項目・配信国の選択・広告IDの確認・審査に出すボタンの手前まで）は、ぜんぶ ブラウザを動かせるAIが自分で画面をクリックして埋めたよ。人がキーボードで打ったのは、 ほとんど無いんだ。

• Play Console の画面をAIが直接クリックして、必須の11項目・配信国の選択・広告IDの確認まで すすめた。
• 人がボタンを押したのは、後戻りできない最後の一押し（「審査に送信する」等）だけ。

こん太: 「めんどうな入力ぜんぶAIまかせにできるの、すごくラクだね! ぼくらは最後の 『よし出そう!』ってボタンを押すだけでいいんだ!」

たぬ姉: ただし最後の一押しは、いまも人がやる約束。取り消せないボタンを AIまかせにしないの。これは「AIがサボってる」んじゃなくて、わざと人に残してるんだよ。

不具合を直すとき、いちばん時間を食うのは修正そのものではありません。 AIが「実機でどうなっているか分からない」ので、毎回あなたに見てもらう往復です。 「開いて、そこを押して、どう見えるか教えてください」——これが1日に何度も起きます。

直し方は、アプリ自身に自分の状態を数字で申告させることでした。 画面を見なくても、コマンド1回で今の状態が1枚のテキストで出てきます。

• 数える場所を段ごとに置く: 受け取ったN件 → 保存したN件 → 表示したN件。減った段が壊れている場所
• 遅さは実測ミリ秒で持つ（「重い気がする」ではなく、実際に測った秒数で言う）
• 出力はコピペ1枚にまとめる。AIはそれを読むだけで切り分けられる

これで、調査の往復から人が外れました。 「目視をお願いして説明を待つ」が「コマンド1回・数秒」になっています。

• 教訓①: 0件は「起きなかった」ではなく「測っていない」かもしれない。両者は必ず区別する
• 教訓②: 合格・不合格の2つでは足りない。「測れなかった」を足して3つにする。でないと、何も測っていないのに合格と出る
• 教訓③: 検査自身をわざと壊して、ちゃんと不合格になるか確かめる。壊れた検査は、静かに全部通します
• ✗ 効かなかった: 計器を増やすこと自体。読み取りを増やしすぎて診断が817秒かかり、アプリを重くしました（まとめて読む形に直して5ミリ秒）。計器が製品を遅くしたら本末転倒です

考え方の全体はキットの説明書（AIが読む用）に入っています。 新しいアプリを作るときは、作り始める前に読ませてください。 後から計器を足すのは、作りながら足すより何倍も高くつきます。

デスクトップPCとノートPCの間で開発を引き継ぐ仕組み（handoff.mdと、 正本 CLAUDE.md への自動到達経路）を設計した際、その土台となる 「共有フォルダの実体は何か」を、2回続けて検証せずに決めつけました。

• 1回目の決めつけ: 作業フォルダのパスに OneDrive という 文字列が含まれていたため、「OneDrive同期でデスクトップPC・ノートPC間に 自動で伝わる」と実機確認せずに設計・記述した
• 実測での否定: 別プロジェクトを担当していた別セッションから 「このPCではOneDriveはアンインストール済み」と指摘され、実際に Get-Process・実行ファイルの有無・レジストリのアカウント登録・ フォルダの属性（クラウド同期を示す reparse point の有無）を確認したところ、 OneDrive同期エンジンはこのPC上に一切存在しなかった
• 2回目の決めつけ: 同じフォルダパスに含まれていた別の文字列 Resilio を見て、今度は「Resilio Sync（P2P同期ソフト）が実体では」 と、これも実機確認せずに決めつけかけた
• 実際の答え: どちらでもなかった。フォルダの持ち主から 「大きな会社が使うような共有の仕組み」というヒントと、ノートPC側の 実際のエクスプローラ画面（github (¥¥BESTTRUST) (Z:)）の スクリーンショットで、Windows標準のSMBネットワーク共有 （デスクトップPCのホスト名 BESTTRUST が github フォルダを共有し、ノートPCがそれを Z: ドライブとしてマウントしている） だったと判明した

パス名に残っていた OneDrive と Resilio は、どちらも 過去の経緯で残った命名に過ぎず、現在使われている共有方式とは無関係でした。 2回とも、名前から推測しただけで「たぶんこれだろう」を確認済みの事実として扱って しまっていました。

• 教訓①: パス名・フォルダ名の文字列から、動いている仕組みを推測しない。 「〜という名前が付いている」は「〜が実際に動いている」の証拠にならない
• 教訓②: 複数PC・複数の共有方式が候補に挙がる場面ほど、 Get-Process・Get-SmbShare のような実機コマンド、 または相手が実際に見ている画面のスクリーンショットで裏取りしてから設計する （基準③「完膚なきまでの裏取り」は、コードだけでなくインフラの前提にも同じ強度で効く）
• 教訓③: 1度目の誤りを指摘されて確認した直後でも、2度目の思い込み （今度はResilio）が起きた。「1回外れたから次は慎重に」だけでは足りず、 毎回同じ手順（実機確認）を踏む必要がある

設計の結論自体（github/CLAUDE.md への1行インポートで、配下の 全プロジェクトに正本が自動で伝わる）は、共有方式がSMBであっても変わらず有効でした ——ノートPC側もZドライブ経由で同じファイルシステムの実体を見ているためです。 変わったのは「なぜ両PCに伝わるのか」という前提の理解だけでした。

アプリの名前を「マルウェアチェック.site」から「サイト侵害チェック」へ変えて審査に出す直前、 App Store Connect（ASC）には旧いキーワード（マルウェア・感染・スキャン）・旧い名前・旧いサブタイトルが 残ったままでした。提出スクリプトが「前の版の値」を「リポのファイルの値」より優先して引き継ぐ作りで、 ファイルをどう直しても反映されなかったからです。機械は何も止めず、人が提出の直前に ASC を読み戻して初めて気づきました。

• 教訓①: 正本はリポのファイル。外部サービスの現在値を上に置かない。 「前の値を引き継ぐ」は、改名や訴求の変更が原理的に伝わらない
• 教訓②: 取り消せない1手（審査への提出）の直前に、意図（リポ）と実態（ASC）を等値で突き合わせる。 名前・サブタイトル・説明・キーワード・審査メモ・プライバシーURLが1つでもずれたら、提出しない（appstore-submit.mjs の [7g]）
• 教訓③: 書き込みの失敗を警告で流さない（旧い名前が公開される）。改名の取り残しは台帳（identity.formerNames）で検査し、 掲載文の正本ファイルが無いことは IPA を作る前に止める
• 確認のしかた: 実際の ASC に当てて、旧キーワード・旧名・旧サブタイトルが3件の不一致として赤になることを確かめた（毒テスト）

取り消せない操作（push・マージ・デプロイ）の前に「CLAUDE.md を現在の内容のまま全文読んだか」を確かめる門番を作りました。 ところが指示書は1300行を超え、1回では読めません。分けて読むのですが、1行目から読み直すとそれ以前の読みを捨てる作りで、 後半を先に読むと後半が消え、同じ巨大ファイルを何度も読み直す羽目になりました。

• 対処①: 判定を「行ごとに、最後に読んだ版が今の内容と一致するか」に変え、読む順番に左右されないようにした。拒否文には、足りない行範囲を offset／limit の形で出す
• 対処②: 指示書に core:end マーカーを置き、必読の核（431行）だけを判定対象にした。核が太らないよう、上限450行を機械で見張る
• 教訓: 守らせる仕組みのコストは「文書の長さ × 読み直しの回数」。文章のルールを増やすほど、仕組みそのものが「読まない理由」になる。核を小さく保つことも検査の対象にする

使用量ダッシュボードに各頭脳の残量を出したところ、Grok Build の残高切れ（402）・Alibaba の全6モデルの無料枠切れ・OpenRouter の残高切れが同時に起きていました。 自動の切り替えは Cloudflare まで落ちていました。Cloudflare の公式 MCP で今日（UTC）の使用量を取ると、 約72,000 ニューロンで、無料枠 10,000 の約7倍でした。

• 思い込み: 運用の文書に「超えたら止まる（課金されない）」と書いてあった
• 実際: 請求画面で Workers Paid（有料）契約。超えても止まらず、超過分は従量課金になる
• 対処: 文書を訂正し、dispatch に「今日の無料枠を超えていたら、自動では Cloudflare を飛ばす」ガードを入れた（明示指定は止めない・記録が読めなければ止めない）
• 教訓①: 「無料」という言葉を、契約で確かめずに信じない。重い作業は1回で無料枠を超える
• 教訓②: 無料枠は頭脳ごとに別々に切れる。残量を目に見える形にしておかないと、気づいた時には全部切れている

トップページの「実際に使った例」に、改名前の名前「マルウェアチェック.site」と、 「マルウェア感染疑いを簡易診断」という旧い説明が残っていました。審査に出した新しい説明（端末のウイルススキャンはしない）と食い違う、 公開ページの記載でした。手で書く一覧は、名前も状態も古くなります。

• 対処: 名前と説明を直し、トップにいま計った数字（公開アプリの稼働・App Store の最新版と最終更新日・今週の実測）を自動で出すようにした
• 教訓: 公開してよい状態の記載は、手で書かず、毎回計り直す。文章の主張より、実際にアクセスして確かめた数字のほうが強い証拠になる