スマホ完結運用の最大の障害とそれを軽減する方法【スマホで周回！#12】

2026年5月29日 12:04

こんにちは、スマホ投資パパです。

スマホだけでできる米国株の自動分析システムの第12回目になります。

前回（第11回）では、保有銘柄更新をAIで半自動化する話を書きました。

今回は「直したい」と思った瞬間にAIと作業を始められる仕組みを紹介します。第4回サイクル加速編でリポジトリパックに触れましたが、今回はその仕組みを深掘りします。この仕組みができてから、システムの改善サイクルがまったく変わりました。

スマホ完結運用の最大の敵

コードを修正したいとき、自分はClaudeやChatGPTに相談します。でもスマホだと作業開始までが長い。

指示文を書くだけではなく、
GitHubでファイルを探して、全文コピーして、AIのチャット画面に貼る。関連ファイルが複数あれば何度も繰り返す。「あのファイルも渡さないと文脈がわからないな」と思って、またGitHubを開く。

このシステムは10以上の機能があります。毎回手でかき集めると、スマホを何十回もスクロールしてコピーして貼り付けてを繰り返すことになります。

スマホ完結で開発していると、慢性的に手が疲れます。自分はずっと腱鞘炎一歩手前です。若い頃はなんともなかったのに、スマホで無理をすると手首や腕に響くようになってきました。最近のスマホの大型化もあるのか、昔より長時間いじり続けられなくなっています。

今や欠かせない腱鞘炎防止策がこれです。

- スマホ保持手を左右交互に入れ替える
- タッチ指を交互に入れ替える（片手親指↔︎もう片方の人差し指）
- スマホリング
- 手首、指のストレッチ及びマッサージ
- アリナミン摂取
- 腕へのシップ

開発の最大の障害が手の疲れというのは、正直笑えない話です。だからこそ、書く必要のある文字以外はなるべく手数を減らしたい。AIに渡す準備だけで指を酷使するのは、真っ先に省きたい作業です。しかも「本当に最新版のコードを渡せているか」という不安も残る。貼り忘れがあれば、AIが古い情報で修正案を出してきます。

解決策：mainに反映したら最新版が自動でダウンロード待ち

なるべく負担のかかる手数を減らすため、mainにpushするたびに、Actionsが自動でリポジトリ全体をzipに固めて GitHub Releases に上書き公開するようにしました。

zip はリポジトリのテキスト系ファイル（`.py` / `.yml` / `.md` / `.csv` / `.txt` など）を丸ごと1本に固めた `repo-pack.zip` です。スコアを直したいときも保有管理を直したいときも、ダウンロードするものは同じ1本。AIに渡せば全体の文脈をその場で読み込んでくれるので、「どのファイルを渡すべきか」を考える工程が消えます。

スマホでの手順はこうです。

GitHubアプリのメニューからReleasesを開く
`Repo Pack (latest)` の `repo-pack.zip` をダウンロードする
AIのアプリでファイル選択（「最近使ったファイル」から一発）
「ここを直して」と送る

以上です。作業開始まで30秒もかかりません。

そして修正をmainにpushすると、約1分後には最新の zip がReleasesに上書きされています。それをまたAIに渡して「次はここを直して」と送る。このサイクルを何度でも繰り返せます。

一度仕組みを作ってしまえば、「最新コードをAIに渡す」という作業が完全に消えます。手を動かすのは「直したい内容をAIに伝える」ことだけになります。

zip の中に何が入っているか

zip はただのファイル結合ですが、リポジトリ直下に常置してある2つの Markdown ファイルが毎回そのまま同梱されるように設計してあります。これがAIに文脈を渡す装置です。

`.github/copilot-instructions.md`：AIへの制約ルール

「出力はUnified diff形式のみ」「I/O・CSV構造・Slack出力は変更禁止」「曖昧な点は推測せず確認する」といった指示を、このファイル1つに集約してあります。

第5回のガードレール編で書いたルールをそのままファイルに封じ込めたイメージです。zip を渡せばこのファイルも一緒にAIへ届くので、毎回プロンプトに書かなくても、AIがルールを理解した状態で動いてくれます。

このルールがないと何が起きるか。「このスコア計算を修正して」と頼んだだけで、AIが関係のない別の関数まで整理し始めたり、CSVの列構造を勝手に変えたりします。親切心から出た行動ですが、こちらは修正箇所だけを最小限に直してほしい。その意図をリポジトリ直下のファイルで毎回伝えるので、余計な変更が入らなくなります。

`Project.md`：プロジェクト概要・データフロー・用語集

どのファイルが何を受け取って何を出すか、責務分離はどうなっているか、VCPやFTDといった投資系の専門用語の定義は何か、といった情報をこのファイル1つに集約しています。コードだけ渡すと「このファイルは何と連携していますか」「FTDとは何ですか」という確認が往復しますが、それがなくなります。AIがシステム全体と用語を把握した上で修正案を出してくれます。

zip がリポジトリ全体を丸ごと固める方式なので、コードを差し替えてもこの2ファイルは常に同梱される。「ルールとドキュメントは別ファイルとしてリポジトリに常置」というだけの単純な仕組みですが、貼り付けた瞬間からAIが文脈を理解した状態で動く効果は、実際に使ってみると大きく実感できます。

改善サイクルが変わった

Slackに届いたアラートを電車の中で見て「この条件、もう少し調整したいな」と思いついたその場で、Releasesを開いて zip をダウンロードして、AIに「この条件をこう変えたい」と相談できます。修正のdiffが返ってきたら、コーディングエージェントでGitHubに反映して終わりです。反映が終われば1分後にはまた最新版がReleasesに上書きされているので、同じセッションのまま続きの修正に入れます。

移動中に気になって、移動中に解決する。この流れができると、小さな改善が積み重なっていくスピードがまったく変わります。

「ちょっと気になる」レベルの改善を後回しにしなくなったのが一番の変化です。思い立ったときに即動ける状態が、改善の頻度そのものを上げてくれます。改善を先送りにすればするほど「なんとなく気になるけど放置している箇所」が増えていく。その悪循環がなくなり、結果的に周回速度を劇的に上げることができました。

自分のリポジトリにも作れる

同じ仕組みを自分のリポジトリに作りたい場合は、以下のプロンプトを使ってください。

あなたはGitHub ActionsとPythonの専門家です。
以下の仕様でリポジトリパック自動公開の仕組みを作ってください。

【やりたいこと】
mainにpushされるたびに、リポジトリ全体を1つの zip に固めて
GitHub Releases に同一タグで上書き公開したい。
あわせて Actions Artifacts にもアップロードしておきたい。

【パックに含めたい内容】
- リポジトリ内のテキスト系ファイル（.py / .yml / .yaml / .md /
  .csv / .txt / .json / .sql / .toml / .lock）を丸ごと1つの zip に固める
- .git / dist / __pycache__ などビルド成果物・キャッシュ系は除外

【出力してほしいもの】
1. パック生成スクリプト（tools/make_zip_pack.py）
   - リポジトリのルートで実行され、dist/repo-pack.zip を出力する
   - 対象拡張子と除外ディレクトリを定数で指定できる
2. GitHub Actions ワークフロー（.github/workflows/prepare-repo-pack.yml）
   - main へのpushをトリガーに動く
   - paths-ignore で dist/** は無視（自己ループ防止）
   - workflow_dispatch でも手動実行できる
   - actions/upload-artifact@v4 で Artifact 名 repo-pack（30日保持）
   - softprops/action-gh-release@v2 で
     タグ repo-pack-latest に overwrite_files: true で上書き
3. 安定運用のための3点
   - 同じワークフローが2重起動しないよう concurrency を設定
   - pushが必要な場合は rebase 戦略（git pull --rebase --autostash -X ours）
   - ジョブ失敗時にSlack通知（SLACK_WEBHOOK_URL はSecrets登録済み）

フォルダ構成を貼って送るだけで、パック生成スクリプトとワークフローが返ってきます。AIが出してくるものは大きく2つです。1つはPythonのパック生成スクリプトで、対象ファイルを再帰的に集めて1つのzipに固めるシンプルな処理です。もう1つはActionsのワークフローで、mainへのpushをトリガーにスクリプトを実行し、Releasesに上書き公開する流れを担います。

最初はプロンプトの「対象拡張子」と「除外ディレクトリ」を自分のリポジトリに合わせて書き換えるだけで十分です。動かしてみてから「この拡張子も含めたい」「このディレクトリは除外したい」と少しずつ育てていくのが現実的です。

この仕組みを毎日動かすために

zip公開はActionsが安定して動いている前提です。最低限入れておきたい設定を3つ挙げます。上のプロンプトにすでに含めてあるので、フォルダ構成と一緒に送るだけでまとめて実装してもらえます。

同じジョブが2重に動かないようにする

mainへの連続pushや、push直後に手動実行が重なったとき、同じジョブが2つ並走することがあります。Actionsは何も設定しないとトリガーが来た分だけ素直に動くので、「先に動いているジョブが終わるまで待つ」制御を明示的に入れるのが安全です。

pushの競合を防ぐ

パック生成ワークフロー自体はpushしませんが、別のワークフローと同居してリポジトリにpushする運用になったときに必要になります。複数のジョブがほぼ同時にpushしようとすると、どちらかがGitに弾かれます。pushの直前にリモートの最新を取り込んでから自分の変更を乗せる手順を挟むだけで防げます。ジョブの最後でいきなりエラーになる、一番テンションが下がるトラブルです。

失敗したらSlackに通知する

ジョブが失敗してもSlackに通知が来なければ翌朝まで気づきません。エラー時だけ通知を飛ばす設定を入れておきます。「失敗に気づく」と「原因を追える」は別の話なので、通知はあくまで起点です。原因追跡にはActionsのログとArtifactsの保存（30日）を合わせて使います。

まとめ

リポジトリパックの仕組みを一言で言うと、「直したいと思った瞬間に動ける状態を常に保つ」ことです。

手数を減らすことが、スマホ完結運用では品質に直結します。「面倒だから後でいいか」が消えるだけで、改善の頻度がまったく変わります。

次回（第13回）はユニバース編に入ります。分析対象となる銘柄群のメンテナンスを日々どうしていくかの話をまとめます。

スキを押してもらえると、続きの公開が早まります。
気になる部分があればコメントで教えてください。

本記事は、米国株分析システムの実装例を紹介する技術記事です。投資助言ではなく、プログラミング教材・個人の設計ノートとしてご覧ください。実際の投資判断は、ご自身の責任でお願いします。