「動くアプリ」と「公開できるアプリ」は別物だった ― 経理AIのα版公開準備で、直書き8件を掘り出した話

こんにちは！YaroTechです。

昨日の記事で、1週間のAI配分表を公開しました。その表のいちばん上に「大物①：自作の経理アプリのα版GitHub公開準備」と書いて、実装はClaude Codeの増量枠に割り当てました。今日はその大物①に着手した初日です。書いた翌日に手をつける、という当たり前のことをちゃんとやりました。継続投稿377日目、火曜の開発記です。

そして着手して1時間ほどで、思っていたのとは違う結論にたどり着きました。「自分のPCで動いているアプリ」を「他人のPCで動くアプリ」にするのは、機能を足す作業ではなく、剥がす作業だということです。動くアプリと公開できるアプリは、まったく別物でした。

※見出し画像のプロンプトは一番下におまけで公開中！

※2026年7月28日時点の情報です。

🖥️ 実行環境

• PC: ThinkPad X1 Carbon

• OS: Windows 11 Home 25H2

• 実装: Claude Code（モデルはOpus 5・週間上限+50%の増量期間中・実行モードは「編集を受け入れる」）

• 設計相談・判断の壁打ち: Claude Desktop（Fable 5）

• 対象アプリ: YaroTech AI Cowork v0.1.0（自作のバックオフィスAIアプリ。Claude Agent SDK＋FastAPI構成、Webフロントとの接続はWebSocket、会計側はMFクラウド会計MCPのbeta接続先）

実装はクロコ（Claude Code）、設計と判断はクロ助（チャット）。昨日の配分表に書いた「重量級＝Fable／実装＝Code」の役割分担を、そのまま実演した形になりました。

🎯 この記事で得られること

• 個人開発のアプリを公開する前に、実際に何をやることになるのかの実例

• 「自分のPCでしか動かない」の正体は何か（直書きと環境依存の2つです）

• 秘密情報の外出しでいちばん見落とされる場所（コード本体ではありませんでした）

• まっさらな環境でセットアップを試すと何が起きるか

• AIに実装を任せるときの、止める判断と通す判断の線引き

📊 実際の成果（Before/After）

Before（今日の作業前）

• 秘密情報の直書き: 8件（対象ファイル7個）

• 動く場所: 自分のX1のみ

• 接続先やNASのパス、事業者名がコードとドキュメントに埋まったまま

After（作業後）

• コミット前の再スキャンで秘密情報ゼロを確認

• 新規リポジトリに初回コミット1件（mainブランチ・追跡35ファイル・+7,888行）

• まっさらな環境でセットアップから起動までE2Eで成功

所要時間は約71分（16時57分〜18時08分）でした。

ひとつ先に断っておきます。ここでやったのは「自分で決めた9カテゴリのパターンに引っかかるものを探して外に出した」という範囲の作業です。専門的なセキュリティ監査ではありませんし、これで安全が保証されたわけでもありません。あくまで「公開する前に自分でやれることを、やれる範囲でやった」という記録として読んでいただければと思います。

🚀 実践内容

①サニタイズコピーと、9カテゴリのスキャン

最初にやったのは、開発フォルダを一切いじらないことでした。現行のアプリは日々使っているので、そこで公開作業を始めると、間違えたときに戻せません。そこで隣に公開用フォルダを新しく作り、必要なファイルだけをコピーする方式にしました。

クロコの一言はこうです。

これは効きました。新しいリポジトリとして初期化すれば、履歴はゼロから始まります。「昔のコミットに秘密が残っていないか」という、後から調べるのがいちばん面倒な問題が、構造的に発生しなくなるわけです。

そのうえで、開発フォルダ全体を正規表現でスキャンしました。カテゴリは9つ。APIキーの実値、OAuthのclient_secret、Bearerトークン、アクセス／リフレッシュトークン、汎用のAPIキー表記、個人のパス、NASのホスト名、パスワード、そして実際の事業者名です。

結果、直書きが8件、対象ファイルは7個でした。内訳はこうなります。

• APIキーの実値: 1件

• OAuthのclient_secretとトークンの実値: 1ファイル

• NASのホスト名入りのUNCパスの直書き: 3件

• MCP接続先URLの直書き: 2件

• 実事業者名やプロファイル名を含む実データ: 2ファイル

（実際の値やファイル名は当然ながらここには書きません。すべてマスク済みです。）

ここでいちばん驚いたのが、その分布でした。コード本体、つまりバックエンドの主要ファイルからフロントエンドまでは、直書きがゼロだったんです。 環境変数から読むように、ちゃんと書いてありました。

では8件はどこにいたのか。設定ファイルの「環境変数を読むときの既定値」と、ドキュメントの中でした。

これが今日いちばんの発見です。環境変数化したつもりでも、読み込みの既定値に本物を書いてしまうと、それは直書きと同じです。しかも見た目は「ちゃんと外出ししているコード」に見えるので、目視ではまず気づきません。コード本体は綺麗でも、既定値とドキュメントに秘密が染み込んでいた ── これが「動くアプリ」の実態でした。

外出しの作業自体は淡々としたものです。すべてを.envから読むようにして、.env.exampleを全項目コメント付きで書き直し、.gitignoreを整えました。コミット前にもう一度スキャンをかけて、作業ツリーの36ファイルではヒットが2件（自分で作ったダミーのパス表記だけ）、ステージ済みの35ファイルの中身を直接再スキャンして0件。ここまで確認してから初回コミットを打っています。

関連記事: このアプリをどう作ったかは経理の"同僚"は、こう作った ― Claude Agent SDK×FastAPI×MFクラウドMCP開発記に詳しく書いています。今日の記事は、その回の最後で予告した「公開までの顛末」の前半戦です。

②接続先とアカウント設定を、設定ファイルへ

次にやったのが「私の環境の前提」を全部引っぺがす作業です。

設定ファイルに書かれていたコード内の既定値を全廃して、すべて.envから読む必須項目にしました。MCPの接続先URLも、.env.exampleからコピーして自分で入れてもらう方式です。未設定のまま起動した場合は、必要な項目が足りていないことを検出して、起動時のバナーで「何が足りないか」「どうすればいいか」を出すようにしました。

複数の事業者を扱う場合の設定も入れています。プロファイルをカンマ区切りで並べて、表示名を上書きできる形です。ただし切り替えは設定を変えて再起動する方式で、画面上の動的な切り替えはやっていません。もともとこのアプリは「1台のPCで1事業者」を原則にした設計で、そこを崩すのは大きな設計変更になるからです。この判断はREADMEにも明記しました。できることより、できないことを書くほうが大事だと思っています。

NASのエクスポート先も同じ扱いにしました。設定ファイルとエクスポート用スクリプトの両方から、実際のNASのホスト名を削除。空欄なら機能そのものが無効になり、未設定で実行したときは設定例つきの案内を出して終了するようにしています。

クロコのこの指摘で、案内文を足しました。エラーメッセージの親切さは、公開するアプリでは機能のひとつです。

③READMEの刷新と、まっさらな環境での検証

最後が今日のいちばんの山でした。

まずREADMEを全面的に書き直しました。前提環境の表、セットアップの5手順、.envの設定表、起動方法、モード判定の表、複数事業者の設定、注意事項、トラブルシューティング10項目、そして構成図。「私が読んで分かる」ではなく「初めての人がこれだけで動かせる」を基準にしています。

そのうえで、一時フォルダに公開用の中身をコピーして、新しい仮想環境を作って、READMEの手順だけを頼りにセットアップを実行しました。結果はこうです。

• セットアップスクリプトが完走（Pythonのパッケージ39個をインストール、フロント側の依存関係も導入完了）

• バックエンドが起動し、ヘルスチェックが200を返す

• フロントの開発サーバーも起動し、ブラウザ側も200

さらに、会計側の認証をしていない状態でも「APIキーがサンプル値のままです」「認証情報のファイルが見つかりません。このコマンドを実行してください」と、具体的な対処が画面に出ることまで確認できました。動くことより、動かないときにちゃんと教えてくれることのほうが、初見の人には大事です。

ただし、ここに至るまでに5つほど転びました。次の章に書きます。

⚠️ つまずきポイントと解決策

つまずき1: バッチファイルの括弧が、ブロックを勝手に閉じていた

セットアップスクリプトが、パッケージのインストールが終わった直後に「. was unexpected at this time.」というメッセージで異常終了しました。

原因は、条件分岐のブロックの中に書いた説明文でした。その説明文に括弧を使っていて、その閉じ括弧がブロックそのものを閉じてしまっていたんです。同じ書き方が4か所ありました。

これ、開発版から前々からあったバグです。でも一度も踏んでいませんでした。理由は単純で、自分の環境ではもうセットアップが終わっているので、そのスクリプトを最初から通しで走らせる機会がなかったからです。「自分の環境では動く」の典型がこれでした。 対処は括弧をやめただけです。

つまずき2: サンプル値は「空ではない」ので、未設定チェックをすり抜ける

これは地味ですが怖いやつでした。

.env.exampleに書いてあるサンプル値をそのままコピーして使うと、設定項目には文字が入っています。つまり「未設定かどうか」を空かどうかで判定していると、サンプル値のままでもチェックを通過してしまうんです。そして実際に接続しにいく段階まで進んでから、意味の分からないエラーで落ちます。

対処は、サンプル値そのものを検出する処理を設定側に追加すること。「値が入っているか」ではなく「本物が入っているか」を見るようにしました。

つまずき3: 除外設定の書き方ひとつで、フォルダごと消える

公開したくないフォルダを除外する設定で、フォルダ名だけを書くとフォルダ自体が丸ごと対象外になり、中に置いておきたい空フォルダ維持用のファイルまで一緒に消えてしまいます。

対処は、フォルダそのものではなく「その中身」を指定する書き方に変えること。こうすると、空フォルダを維持するためのファイルだけを個別に戻せるようになります。除外設定は、書いた瞬間は正しく見えて、後から気づくのがいちばん遅いところです。

ほかにも、スクリプトの起動方法によって現在地の扱いが変わって元の場所に戻れなくなる問題や、コマンドの成功判定が条件分岐の中では期待どおりに動かない問題も踏みました。どれも「まっさらな環境で、READMEの手順だけを頼りに動かす」をやらなければ、永遠に見つからなかったものです。

💡 応用例

公開前チェックを3点に一般化する

今日やったことは、たぶんどんな個人開発にもそのまま使えます。

1. 秘密情報を外に出す（コード本体だけでなく、読み込みの既定値とドキュメントの中も見る）

2. 接続先とパスを設定化する（自分の環境の前提を、全部設定ファイルへ）

3. まっさらな環境で検証する（手順書だけで動くか。エラーの親切さまで見る）

順番も大事だと思いました。1を飛ばして3をやると、検証用の一時フォルダに秘密が入ったコピーが残ることになります。

「読みは自動、書きは関所」という運用

今日の実装は「編集を受け入れる」モードで進めました。読み取りは常に許可、書き込みは都度確認です。ただ、全部の確認を真面目に読んでいたら71分では終わりません。

そこで、指を止める場面を5つだけに決めました。宛先が違う書き込み、フォルダの外に出る操作、取り消せない削除、秘密の実値を画面に出す操作、そして頼んでいない大工事です。それ以外は流します。

実際の例を挙げると、途中で残ってしまった古いプロセスを掃除するために、停止コマンドとフォルダ削除の要求が来ました。削除系なので指が止まります。宛先を見ると、クロコが自分で作った一時フォルダでした。だから通す。ここまで3秒です。

面白いのは、これがアプリ側の設計思想とまったく同じ形をしていることです。このアプリは「読み取りは自動、書き込みは必ず人間が承認」という設計で作りました。それを作っている自分自身が、AIに対して同じ運用をしている。人がAIに仕事を任せるときの作法は、階層が変わっても同じ形になるのかもしれません。

関連記事: なぜこのアプリを作ったのかという話は「仕事を奪うAI」を、自分の手で雇ってみた ― 経理の"同僚"を作った夜に考えたことに書いています。

増量期間に、重い整備を寄せる

昨日の配分表の実演としても、今日は分かりやすい結果が出ました。作業前後で使用量メーターを見比べたところ、全体は15%から16%、Fable枠は17%から18%と、それぞれ1ポイントしか動いていません。セッションのメーターは10%から26%まで上がりましたが、こちらは時間で戻る枠です。

71分の実装作業で週間の予算がほぼ減らなかったのは、実装をClaude Codeの増量枠に寄せたからです。期限つきの増量施策があるうちに重い整備を持っていく、というのは配分表の狙いそのものでした。

関連記事: この配分表の全文は最強を92%まで使い切った私が、月曜に"線"を引き直した話 ― 1週間のAI配分表、公開しますに載せています。

コミットの作者情報も、公開情報です

最後にひとつ、盲点だったものを。

コードから秘密を全部抜いても、コミットには作者の名前とメールアドレスが記録されます。これは公開リポジトリでは誰でも見られる情報です。今回はメールアドレスを公開しない形式（noreply形式）を選んで初回コミットを打ちました。

隠すべきものはコードの中だけにある、と思い込んでいると、ここを素通りします。

🔗 関連記事

今回の内容に関連する過去記事もぜひご覧ください：

• 経理の"同僚"は、こう作った ― Claude Agent SDK×FastAPI×MFクラウドMCP開発記

• 最強を92%まで使い切った私が、月曜に"線"を引き直した話 ― 1週間のAI配分表、公開します

• 「仕事を奪うAI」を、自分の手で雇ってみた ― 経理の"同僚"を作った夜に考えたこと

📝 まとめ

71分の作業でしたが、得たものははっきりしていました。

「自分のPCでしか動かない」の正体は、直書きと環境依存でした。 機能が足りないわけでも、設計が悪いわけでもありません。自分の環境の前提が、コードとドキュメントの中に静かに溶けているだけです。

そしてその前提は、思っていた場所にはありませんでした。コード本体は綺麗だったのに、環境変数の既定値とドキュメントに8件残っていた。「外出ししたつもり」がいちばん危ないのだと分かったのが、今日の収穫です。

もうひとつ。まっさらな環境で動かしてみるまで、バグは2つとも眠ったままでした。動作確認は、自分のPCの外でやって初めて完成します。

念のためもう一度書きますが、今日やったのは自分で決めた範囲のスキャンと整理であって、専門的なセキュリティ監査ではありません。公開の前に自分でできることをやった、というだけです。それでも、やる前とやった後では、公開ボタンを押すときの気持ちがまったく違うだろうな、とは思います。

「公開できる状態」までは来ました。押すのは、まだ先です。

🚀 次回予告

明日は水曜のニュース枠です。大きな動きがあればニュース解説を、なければこの公開準備の続きをお届けします。

そして金曜には、この話の完結編を予定しています。実際にリポジトリを公開して、URLをお見せするところまでが後半戦です。その前に片づけておくべき宿題もひとつ残っていて（開発フォルダ側の過去の履歴の点検です）、そこも含めて書くつもりです。

🎨 おまけ：見出し画像作成プロンプト

今日の見出し画像のベースはジミー（Gemini）に下記プロンプトで作成してもらいました！：

詳細なアニメの美意識の画像を作成してください。表情豊かな瞳、なめらかな網掛けセルの色使い、繊細な線画で、アニメ作品のワンシーンのように仕上げてください。
下記条件のnote見出し画像を、サイズは横長で作成してください。サイズは必ず横長で作成してください。

1. スライドサイズ（1536×1024px）の横長フォーマットで作成する
2. 夜の作業部屋を背景にし、濃紺から黒へ落ちるグラデーションと、モニタの光による淡い青の照り返しを設定する
3. 画面中央やや右に少年（黒パーカー・ヘッドフォン・無表情でクールな雰囲気）を配置し、モニタの前で段ボール箱に荷物を詰めるポーズにする（添付画像と照合。クリーム色ニットの女性にしない）
4. 手前の段ボール箱3つに「.env」「config」「README」のラベルを貼り、アプリの部品を詰めている様子を描く
5. 正面のモニタ画面に赤い「TOKEN」タグを8枚描き、それを剥がして鍵マークの付いた箱へしまう動きを表現する
6. 左側のサブモニタに緑のチェックマークを表示し、検証が通った状態を示す。背景の窓の外には星空を描く（企業ロゴ類は描かない）
7. テキストを3段構成で追加する（上段30〜32pt白「動くアプリと、公開できるアプリは別物」／中段44〜48ptゴールド「α版、公開準備はじめました」／下段20〜22pt白「直書き8件を、71分で外に出した夜」）
8. 下部中央寄りに「YaroTech」のロゴを12ptで控えめに配置する（右下ではない）
9. キャラの参考画像（C:\Users\YourName\Downloads\note\AI擬人化\Gemini_Generated_Image_クロコ（Claude Code）.png）1枚を添付して人物の一貫性を確保する

#YaroTech #生成AI #ClaudeCode #個人開発 #AIエージェント #GitHub #セキュリティ #Python #開発日記 #AI活用