なぜAIチームにVisionとSSOTが必要なのか

スキマ開発のためのAIチーム設計論

本記事は「スキマ開発のためのAIチーム設計論」第2回です。

— 役割分担から始めると失敗しやすい理由

チームを作るとき、 いきなり役割分担から入るとうまくいかないことが多い。

想定外の条件が発生するたびに、

  • これは誰の担当か？
  • どこまで判断していいのか？
  • 例外処理は誰が決めるのか？

といった調整や判断が、その都度必要になる。

人間同士のチームでも頻発するこの問題は、 AIを含むチームでは、より顕著になる。

サッカーで考えると、わかりやすい

サッカーで、 「君は右サイド」「君は中央」とだけ決めて試合に出るチームは、まず機能しない。

  • フォーメーションは崩れる
  • 想定外の状況に対応できない
  • 監督の指示待ちになる

これは、役割だけを定義したAIチームと同じ構造だ。

これはAI特有の問題ではない

この話は、AI以前から知られている。

たとえば、

  • Team Topologies

    チームは役割ではなく、 認知負荷と責務の境界 を設計するもの

  • Agile / Scrum

    プロセスよりも 価値観と原則の共有 を優先する

  • ミッション型組織論

    判断を現場に委ねるには、 判断軸の明文化が不可欠

共通しているのは、

行動を細かく指示しなくても 判断が揃う状態を先に作る

という考え方だ。

Vision：ゴールではなく「判断の向き」

Visionは完成形の仕様書ではない。

  • どの方向を優先するのか
  • 何をトレードオフとして許容するのか
  • 迷ったとき、何を基準に戻るのか

これを言語化したものだ。

人間のチームでは暗黙知として共有されがちな部分も、 AIには明文化されていないと存在しない。

Visionは「到達点」ではなく、 判断が迷ったときの向きを揃えるためのものだ。

Principles：自律のための制約

Principles（原則）は自由を奪うものではない。

むしろ、

  • 何をしないか
  • どこまで踏み込まないか

を決めることで、 現場（AI含む）が自律的に動けるようになる。

これは、

  • Amazon の Leadership Principles
  • Agile の Values & Principles

などでも繰り返し語られている考え方だ。

Visionが「向き」だとすれば、 Principlesはガードレールに近い。

判断は、どのように行われるべきか

では、VisionとPrinciplesがあれば、 AIチームは自然にうまく判断できるのか。

答えは No だ。

判断は「存在する」だけでは足りない。 どういう順序で参照されるのか が定義されていなければ、 結局その場しのぎになる。

たとえば想定外が起きたとき、判断は次の流れを辿るべきだ。

  1. Visionに照らして、向きが合っているかを確認する
  2. Principlesに反していないかを確認する
  3. それでも判断できなければ、 あらかじめ定めたエスカレーションに従う

重要なのは、 「誰が決めるか」ではなく 「どう考えるか」が揃っていることだ。

なぜ、判断は揃わなくなるのか

ここで多くのチームがつまずく。

VisionもPrinciplesも定義した。 にもかかわらず、判断がバラつく。

原因の多くは、

  • 判断軸が会話ログに埋もれる
  • 最新の前提がどれかわからない
  • 人やAIごとに解釈が微妙にズレる

という状態にある。

これは、 「口頭指示だけで回る組織」が破綻するのと同じ構造だ。

Single Source of Truth（SSOT）が必要な理由

SSOT（Single Source of Truth）という言葉自体は、 もともと データ管理・構成管理 の文脈で使われてきた。

真実は一箇所に集約されているべき （Database / Configuration Management）

この考え方は、そのままチーム運営にも適用できる。

判断の前提が散逸している限り、 どれだけ良いVisionやPrinciplesがあっても機能しない。

対話ログはSSOTにならない

Chatログや会話履歴は便利だが、

  • 最新かどうかわからない
  • 判断の背景が埋もれる
  • 正解が一意に定まらない

参照点としては不安定だ。

判断の拠り所が毎回変わる状態では、 自律は生まれない。

SSOTは「チームの憲法」

SSOTは単なるドキュメントではない。

  • Vision
  • Principles
  • 判断の流れ
  • 責務の境界

を集約した、チームの定義そのものだ。

人もAIも、 迷ったらここに戻る。

管理を増やす話ではない

この設計は、

  • 管理強化
  • ドキュメント主義
  • 手続きを増やすこと

が目的ではない。

スキマ時間で前に進むための、前払いの設計である。

再びサッカーの話に戻ると

強いチームは、

  • 戦術を共有している
  • 例外時も判断が揃う
  • 監督が叫ばなくても動ける

AIチームも、目指す姿は同じだ。

参考・引用

次の記事では、このSSOTを前提に、 AIエージェントの責務分割と運用設計に踏み込んでいく。

スキマ開発のためのAIチームビルディング

スキマ開発のためのAIチーム設計論

本記事は「スキマ開発のためのAIチーム設計論」第1回です。

── 隙間時間でも、プロダクトは前に進められるのか

サッカーの試合を想像してみてほしい。

監督はピッチに立たず、 試合の合間合間にだけ、選手へ声をかける。

「今は攻めて」 「やっぱり守って」 「さっきのプレー、少し変えよう」

指示は断片的で、その場限り。 この状況で、チームは安定して機能するだろうか。

生成AIを対話モードで使った開発は、 どこかこの光景に似ている。

強力なAIが目の前にいる。 だから、その場の会話で何とかしてしまう。 しかし、コントロールは効かず、 中断と再開のたびに流れが切れる。

隙間時間で進めたいはずの開発が、 いつの間にか「張り付ける人」を前提にしてしまう。

この記事は、 そんな違和感から始まった挑戦の記録だ。

本質は、AIの性能ではなく「関係性」

ここで伝えたいことは、とてもシンプルだ。

隙間時間でアプリ開発を成立させる鍵は、 AIの性能ではなく、人とAIの“関係性の設計”にある。

生成AIの活用は、多くの場合 「人とAIのマンツーマン対話」から始まる。

学習、アイデア出し、試作。 このフェーズでは、対話型はとても強力だ。

しかし、開発が進むにつれて 次のようなことが起きやすくなる。

  • 設計と実装が少しずつズレていく
  • どこで何を決めたのかが曖昧になる
  • 中断すると、文脈を取り戻すのに時間がかかる
  • 隙間時間で進めるはずが、逆に疲れる

これは、AIが賢くないからではない。 人とAIの関係性が「その場限りの会話」に依存しているからだ。

マンツーから「小さなチーム」へ

ここで問い直したい。

本当に、AIは「一人の相棒」である必要があるのか？

大げさな「組織」や「マネジメント」を 持ち出したいわけではない。

想定しているのは、 数人規模の小さなチームだ。

  • 設計を考える役
  • 実装を進める役
  • レビューする役
  • 判断材料を整理する役

これらを、人とAIで分担する。

人はすべてを自分で実装しない。 代わりに、

  • 方針を示す
  • レビューする
  • 最後に決める

この立ち位置に回る。

サッカーで言えば、 ピッチ上の全員を直接操作するのではなく、 戦術と役割を決め、 流れを見て判断する監督に近い。

この考え方を、ここでは 「スキマ開発のためのAIチームビルディング」 と呼ぶことにする。

これは特別な発想ではない

この構想は、 生成AI時代の奇抜なアイデアではない。

既存のソフトウェア開発の方法論を、 生成AIに当てはめ直しただけだ。

たとえば Team Topologies では、 成果はツールよりも 「チーム構造」に強く依存するとされている1。

また、Conway’s Law が示す通り、 作り手のコミュニケーション構造は そのままシステム構造に反映される。

対話型AIだけで進める開発が 密結合になりやすく、 ズレを生みやすいのは、 ある意味で自然な結果だ。

さらに、 「判断は人が持つ」という前提は ADR（Architecture Decision Record） の考え方に支えられている2。

AIは提案し、整理し、比較する。 決めるのは常に人。 判断そのものを、後から振り返れる形で残す。

この線引きが、 隙間時間での継続を支えてくれる。

これは銀の弾丸ではない

すべての開発に万能な方法ではないし、 短期間で一気に作るなら、 マンツーマンの対話型AIの方が速い場面も多い。

ただし、

  • まとまった時間が取りづらい
  • 中断と再開を前提にしている
  • 判断や経緯を外部に残したい

こうした条件では、 AIを「チーム」として扱う設計が 現実的な選択肢になる。

技術的には、何をしているのか

やっていること自体は、意外とシンプルだ。

  • AIごとに役割と責務を明示する
  • 判断してはいけない範囲を決める
  • 非対話・バッチ実行を基本にする
  • 判断は記録として残す（ADR）

重要なのは、 AIを制限することではない。

どう使われるかを、先に決めておくことだ。

これにより、人は隙間時間で 「レビュー」「承認」「方向修正」だけに集中できる。

まずは、

  • 設計役のAIを一つ切り出す
  • 「このAIは決めない」と明文化する

それだけでも、体感は大きく変わる。

隙間時間でも、前に進めるために

隙間時間での開発は、 気合や根性では続かない。

必要なのは、 張り付かなくても進む構造だ。

AIを個人としてではなく、 小さなチームの一員として配置する。

それだけで、 開発の重心は大きく変わる。

この試行錯誤の記録が、 同じように隙間時間で開発を続けたい人の ヒントになれば嬉しい。

参考文献

  1. Team Topologies — Matthew Skelton, Manuel Pais https://teamtopologies.com/↩
  2. Architecture Decision Record (ADR) https://adr.github.io/↩

AIと人間とちょうど

IT TIPS

ssh・tmux・moshで変わる「隙間時間の共同開発」

子供の習い事の待ち時間、 通勤電車の数分、 風呂でのスマホタイム。

趣味のアプリ開発は、 こんな「隙間」でしか進まない。

まとまった時間は取れない。 それでも、作りたいものは頭の中にある。

この記事は、 そんな隙間時間で、AIと一緒に作り続けるための話だ。

人間は、 「これからどうしたいか」の方向だけを覚えている。 細かい理由や処理の詳細なんて、 時間が経つと薄れていく。

ちょうど

人間とAIの違い

AIは有能だ。 コードを書き、設計を考え、答えを返してくれる。

でもひとつだけ弱点がある。

セッションが切れると、「これまでの流れ」を理解しづらくなる。

人間は曖昧でも積み上げている感覚を持つが、 AIは切断ごとに、前提を失いやすい。

人間とAIがうまく噛み合うには、 単に質問に答える道具以上の関係と環境が必要だった。

1. 同じ時間に集まる関係（ssh）

まずは単純に繋いでみた。

ssh → gemini CLI

同じ時間に集まる必要があるので、

  • 迎えが来たら中断
  • 電車を降りれば終了
  • 次につなぐときは、また最初から説明

これは、 一緒に予定を合わせて作るパートナー という関係だ。

でも、隙間時間の多い生活では続かない。

2. 作業場所を共有する（tmux）

次に tmux を入れた。

ssh → tmux → gemini CLI

AIは、 同じ場所に居続けられるようになった。

これは、 毎回説明し直さなくてよくなった という変化でもある。

人間は、 夜の10分、朝の数分、 その場所に立ち寄るだけ。

前回の続きをそのまま見られるのは快適だが、 直接の接続はまだ不安定で、 細切れ時間とは相性が良くない。

3. 隙間時間を前提にする（mosh + tmux）

そして mosh を入れた。

mosh → tmux → gemini CLI

ここで関係は一気に変わった。

  • 人間はどこからでも立ち寄る
  • AIは同じ場所で思考を積み上げる
  • 切断は前提、再接続は自然

子供の待ち時間に方向を投げる。 通勤で返答を眺める。 お風呂でちょっと修正する。

それだけで、 次にまとまった時間が取れたとき、 ちゃんと前から続けられる。

ちょうどいい関係

人間は曖昧な方向を覚え、 AIは文脈を積み上げる。

その役割を活かす環境が揃ったとき、 初めて一緒に作る感覚が生まれた。

AIとにんげんとちょうど。

隙間時間が多い今の生活では、 mosh + tmux + AI が、今の自分にはいちばん自然にフィットしていた。

補足：技術的な説明（用語整理）

本文では関係性や距離感の話を中心にしたため、 ここでは登場したツールを技術的な役割として簡単に整理しておく。

gemini CLI

Google Gemini をコマンドラインから利用するためのツール。

  • 対話形式で指示を出せる
  • コード生成・設計相談・文章生成などが可能
  • 実行環境やセッションの状態は、呼び出し元に依存する

単体では セッションが終了すると文脈は保持されない。

ssh

Secure Shell の略。

  • ローカル端末からリモートマシンに接続するための仕組み
  • 接続中のみ操作が可能
  • 切断されると、そのセッションは終了する

ssh 自体は セッションの継続や復帰を考慮した設計ではない。

tmux

ターミナルマルチプレクサ。

  • 1つの接続で複数の仮想端末を管理できる
  • セッションを切断しても、プロセスや画面状態を保持できる
  • 再接続時に、同じ状態から作業を再開できる

tmux によって AIプロセスや作業状態をサーバ側に常駐させることができる。

mosh

Mobile Shell。

  • ssh をベースにしたリモート接続ツール
  • 一時的な切断や IP 変更に強い
  • 再接続時に、同じセッションを自然に復元する

移動中や不安定なネットワーク環境を 前提として設計されている点が特徴。

構成として何が起きているか

mosh → tmux → gemini CLI

この構成では、

  • gemini CLI：AIの処理・思考
  • tmux：状態・セッションの保持
  • mosh：不安定な接続からの安全な出入り

という役割分担になる。

結果として、

  • AIは同じ環境で連続した文脈を保ちやすく
  • 人間は短時間・断続的に関与できる

という状態が作られる。

構成 向いている場面 つらい点
ssh + gemini CLI 同じ時間が取れるとき 途切れやすい
ssh + gemini CLI on tmux 続きから作業したいとき 移動に弱い
mosh + gemini CLI on tmux 隙間時間を活かしたいとき 初期設定だけ少し必要

リモート作業がさらなる進化！WireGuard ベースのメッシュ VPN「Tailscale」

IT TIPS

Tailscaleのススメ

〜グローバルIPがなくても「家と同じ開発環境」を持ち歩く〜

グローバル IP を持たないマンション回線でも、 外出先から自宅 PC に安全に SSH ログインし、生成AIを活用した開発を続けたい。 できることなら、低コストで実現したい。

これは、少し前まで「それなりに頑張らないと難しい」課題でした。

私自身、この問題に対する解として、以前 「VPS を使ったリバース SSH トンネル」の構築・運用ガイドを記事にしています。

（関連記事）

この構成は今でも有効ですが、 同じ目的を、もっと簡単に・もっと安全に・しかも低コストで実現できる方法が、 すでに一般的になっていました。

それが Tailscale です。

本記事では、 なぜ Tailscale が「リバース SSH 構成の上位互換」と感じられるのか、 そして実際にどのような使い方ができるのかを紹介します。

進化するVPN

この記事でわかること（ゴール）

この記事を読み終えると、次のことが理解できるはずです。

  • グローバル IP を持たない自宅 PC に 外出先から安全に SSH 接続する 現時点での最適解
  • Tailscale が なぜ簡単で、なぜ安全で、なぜ速いのか
  • VPS + リバース SSH 構成と比べたときの 設計思想の違い
  • Tailscale を前提にした 現代的なリモート開発スタイルの一例

専門用語については、 本文では流れを優先し、後半に用語集としてまとめて解説します。

まず結論：Tailscale で何ができるのか

Tailscale を使うと、次のことが“特別な設定なし”で成立します。

  • 外出先のノート PC / iPhone から
  • グローバル IP を持たない自宅 PC に
  • 直接 SSH 接続
  • 低遅延・高スループット
  • セキュアな暗号化通信で

「家で作業していた続きを、そのまま外で続ける」 ──これが、意識せずに実現します。

スキマ時間でも「開発が進む」という体験

このスタイルが特に活きるのは、 腰を据えて作業するほどではない時間です。

  • 通勤中の電車内

    • 前日に走らせた処理結果を確認
    • ログを見て、次に試す方針を指示

  • 子供の習い事の送り迎えの待ち時間

    • AI に修正方針を伝える
    • テスト条件を変えて再実行

  • ちょっとしたスキマ時間

    • tmux セッションの状態確認
    • 長時間ジョブの完了チェック

このとき、iPhone でコードを書く必要はありません。

  • やりたいことを文章で指示する
  • 実行や試行錯誤は自宅 PC 側で進む
  • 結果は後でまとめて確認する

「作業時間」と「思考・指示の時間」を切り分けられる ──これが、Tailscale 前提のリモート開発の強さです。

Tailscale の強み①：導入がとにかく簡単

  1. 自宅 PC に Tailscale をインストール
  2. 外出先の PC / スマホにもインストール
  3. 同じアカウントでログイン

これだけです。

  • VPN サーバ構築不要
  • 鍵管理不要
  • ルータ設定不要

インストール直後から SSH できるのは、正直かなり衝撃的です。

Tailscale の強み②：なぜセキュアなのか

  • WireGuard ベースの暗号化通信
  • ID（ユーザー・デバイス）ベースの認証
  • デフォルトで外部公開なし

SSH ポートをインターネットに晒す必要はありません。

「誰が・どの端末から・何にアクセスできるか」を 明示的に制御できる点は、 ZTNA（Zero Trust Network Access）的な安心感があります。

Tailscale の強み③：高速

可能な限り端末同士を 直接接続（P2P） するため、

  • VPS 経由の遅延がない
  • 無駄な中継がない
  • SSH / Git / rsync が快適

「VPN 越しなのに遅くない」という体験になります。

Tailscale の強み④：個人利用なら無償

個人の趣味開発であれば、 無償プランで十分なケースがほとんどです。

VPS の維持費や、 「止め忘れによる課金」を気にしなくてよくなるのも大きな利点です。

この開発スタイルを一言で言うと

場所や端末に依存せず、 自宅の強力な実行環境を使い続ける開発スタイル

これが、 Tailscale を前提にして初めて自然になる 現代的なリモート開発の一例です。

まとめ

Tailscale は、

  • 簡単
  • セキュア
  • 高速
  • 無償（個人利用）

を満たしながら、

「外出先でも、家と同じように開発できる」

という体験を、ごく自然に実現してくれます。

VPS + リバース SSH は今でも有効ですが、 これから同じ目的で構成を組むなら、まず Tailscale を試す ──それが、今の結論です。

スパイスカレーと生成AIと

休日クッキング

スパイスから学ぶAI活用

休日は、自分専用のアプリを生成AIと一緒に作る時間。 しかし、AIにどう伝えても、思った通りに動かないことがあります。

では、AIがまだ理解できない世界ってどんなものだろう――そう思って作り始めたのが「スパイスカレー」でした。

スパイスカレー

五感とカレーとAI

カルディで買ったインド式スパイスカレーのセット。
袋を開けた瞬間の香り、炒めるときの音、ココナッツミルクの甘さからスパイスの刺激へ移り変わる味。
AIではまだ伝えられない、五感で感じる体験がそこにありました。

一方で、「このカレーに合う具材をAIに聞いてみたい」と思ったのです。
Geminiからは「画像ファイルはこの会話では利用できません」のツレない返事。

香りや辛さ、さらに文脈などの情報は、まだAIにデータとして伝えられません。
ここで実感したのは、AIと深くコミュニケーションするには、情報を意味のあるデータとして渡す必要があるということです。

AI活用に必要だと思ったこと

カレー作りをしながら考えたのは、AI活用で本当に大事なのは次の4点だということです。

  • データ化：人間の五感や曖昧な体験も、AIに伝えるには「意味のあるデータ」に落とし込む必要がある
  • マルチモーダル：画像、音声、テキストなどを組み合わせることで、体験に近い形でAIに伝えられる
  • Webとの結合：リアルタイムの知識や情報を取り込むことで、現実的な洞察に近づける
  • コンテキストの共有：ユーザが欲しい情報は文字だけでは伝わらない。現在の行動やこれまでの経緯をデータ化してAIに渡すことが不可欠

カレーはレシピ通りに作ればおいしい。
しかし「今日は子ども向けに辛さ控えめに」「昨日の残り物を活かそう」といった判断は、その時々の文脈があるからこそ生まれます。
AIも同じで、「過去と今のコンテキストを含めて伝える仕組み」があって初めて、ユーザに本当に役立つ答えが返ってくるのです。

まとめ

  • スパイスから作るカレーは、AIにはまだ再現できない五感の体験を思い出させてくれる
  • AI活用では「データ化」「マルチモーダル」「Web情報との結合」「コンテキストの共有」が鍵
  • 日常のささいな体験からでも、AIの可能性と限界を考えるきっかけは得られる

休日のキッチンでのひとときが、意外にもAIとの向き合い方を考える時間になりました。

材料（使った具材）

  • スパイスミックス（スパイスから作るインド式カレー）
  • サラダ油：60g
  • ニンニク：チューブ8g
  • しょうが：チューブ15g
  • 玉ねぎ：中1.5個（約250g）
  • ホールトマト缶：1缶（カルディで購入）
  • エビ：5尾くらい
  • にんじん：1本
  • ジャガイモ：中2個
  • 塩：小さじ2
  • 水：300cc
  • ココナッツミルク：1缶（400ml、カルディで購入）

作り方

  1. ほっとく鍋にサラダ油を入れて中火で熱す
  2. 玉ねぎをチョッパーで粗みじんにして中火で6分ほどしんなりするまで炒める
  3. ニンニクとしょうがを加えてさらに2分炒める
  4. ホールトマトを加え、崩しながら5分炒める。途中でにんじんとジャガイモも加える
  5. スパイスミックスを加えて2分炒める
  6. ココナッツミルクと水を少しずつ加え、一煮立ちしたら蓋をしてほっとく鍋で20分放置
  7. エビと塩を加え、弱火で3分煮込む

休日に自分だけのスパイスカレーを作るのは、ちょっとした気分転換におすすめです。
カルディの「スパイスから作るインド式カレー」と「ほっとく鍋」があれば、簡単におうちで本格カレーを楽しめます。 ちなみに、子どもには辛すぎたので、急遽「マイクラカレー」を用意しました！

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

スパイスからつくるインド式カレー 20g
価格：980円～（税込、送料無料) (2025/9/23時点)




低コストで安全！VPSを使ったリバースSSHトンネルの課金実績

IT TIPS

リバースSSHトンネルでのリモート接続って、いったいどれくらいお金がかかる？

前回の記事で紹介したリバースSSHトンネル運用の 実際の課金状況 をまとめます。
今回は筆者が 2025/9/13〜9/16、9/20、9/21 に一日数時間のみ利用したケースで、約270円/月 程度となりました！ nw-question.hatenablog.com

How much?

目次

1. 利用状況サマリ

  • 期間: 2025/9/1〜2025/9/21
  • 実際の利用日: 6日間（9/13〜16、9/20、21）
  • 運用方針: 作業後は必ずインスタンスを停止
  • 目的: 必要な時だけ起動することで、従量課金を活用し低コスト運用

停止中の料金目安

  • VPSを停止している場合でも、ディスクやスナップショットなどの固定費が発生
  • 本ケースでは ç´„106円 ÷ 21æ—¥ ≒ 5円/æ—¥ 程度が最低料金としてかかります

休日に数時間だけ利用した場合の目安

  • CPU・メモリは 使用時間分だけ課金
  • 例：休日に4時間だけVPSを起動した場合
    • CPU: ç´„18円 × (4時間 ÷ 5.723時間) ≒ 13円
    • メモリ: ç´„10円 × (4時間 ÷ 22.893 GiB時間) ≒ 2円
  • 合計：15円程度 + 固定費 5円 ≒ 20円/æ—¥ 程度で運用可能

⚡ 少ない利用時間でも、必要な時だけ起動すれば低コストで維持できることがわかります。

2. 課金内訳（実績）

サービス 説明 使用量 単位 費用（¥） 補足説明
Compute Engine Balanced PD Capacity（ブートディスク） 7.176 GiB/月 106 VPSが使う「ハードディスク」の料金。停止中でも保存している限り課金される固定費。
Compute Engine E2 Instance Core running in Americas 5.723 時間 18 VPSのCPUを使った時間の料金。起動している時間に応じて課金される従量課金。
Compute Engine E2 Instance Ram running in Americas 22.893 GiB時間 10 VPSのメモリを使った時間の料金。CPUと同じく従量課金。
Compute Engine Storage PD Snapshot in US 0.944 GiB/月 9 VPSのバックアップ（スナップショット）の保存容量に対する料金。
Compute Engine Multi-regional Snapshot upload 1.1 GiB 3 スナップショットを他の地域にアップロードした際のデータ転送料金。
VM Manager VM Manager Usage (Cloud Ops) 27 count 12 VPSの管理・監視サービスを使った料金。運用の補助費用。
Networking Network Intelligence Center 各種 27 count 11 （合計） ネットワークの状態を分析するサービスの利用料金。微量の固定費的な課金。
合計 143 6日間の利用でこの金額。Free Tier適用で一部マイナスになり、最終合計は143円。

⚠ Free Tier適用分で E2 Core/Ram課金が-28円 になっており、最終小計は 143円 です。

3. 考察

  • 停止運用の効果: CPU・メモリは使用時間のみ課金され、低コストに抑えられた。
  • 必須コスト: ブートディスク（Balanced PD）やスナップショットは、停止中でも課金継続。
  • ネットワークリソース: 外部IPやネットワーク分析は、短時間利用でも微量課金。

4. GCP課金レポートの確認方法

GCPでは、利用状況をGUIで簡単に確認できました。

  1. Google Cloud Consoleにログイン
  2. 左メニュー → 「課金」
  3. レポートを選択
  4. サービス別・SKU別でフィルタリング可能
    • 例: Compute Engine → Balanced PD Capacity でディスク課金を確認
      GCPでの課金レポート

5. Gemini Cloud Assistでの確認（プレビュー機能）

  • Google Cloudのプレビュー機能 Gemini Cloud Assist で、
    「SSH-Relayプロジェクトにおける費用のSKU別内訳」 を記載するとほしい情報が自動で表示できました。
  • 特徴：
    • 日付範囲やプロジェクトを指定してレポート表示
    • SKU別の利用量と料金をグラフで確認可能
    • CPU・メモリ・ディスク・ネットワークなど、課金対象ごとに一目で把握
      Gemini Cloud Assist機能利用

6. 学びと次の運用ポイント

  • ディスク課金: ブートディスクは停止中でも必須課金
  • 従量課金: CPU・メモリは分単位課金で低コスト維持
  • 課金確認: GCPコンソール・gcloud・Gemini Cloud Assistを組み合わせると、より正確に課金を把握できる

まとめ

  • 今回の実績をもとに、休日に 数時間だけVPSを利用する場合の月当たり費用目安 を計算すると以下の通りです。
    • 停止中の固定費（ディスク・スナップショット等）：約 5円/æ—¥ × 30æ—¥ ≒ 150円
    • CPU・メモリの従量課金（休日のみ利用、4時間/æ—¥ × 8日間/月）：約 15円 × 8æ—¥ ≒ 120円
  • 合計：約270円/月 程度で、低コストで安全にリモートアクセス環境を維持可能
  • 「必要な時だけ起動」運用と、ディスク課金の把握がコスト最適化の鍵

開発レポート（「共同推進者」としてのAI活用スキーム　計画作成編）

IT TIPS

AIと二人三脚でアプリ開発：「安心」できるマップづくり

こんにちは！前回、AIを「共同推進者」にするという話をしました。今回はその実践編。AIと一緒に、私が開発中のアプリ「AIService」（生成AIを活用したじぶん専用アプリ開発の生産性を上げるためのサービス機能）の開発計画を作ってみたので、その結果を公開します。

正直、「AIのつくる計画、見せ方で十分に理解・納得して進めることができるのか？」と半信半疑でしたが、これは使える！

AIとのマップづくり

目次

今回の開発環境の前提

まず、今回の開発環境についてお伝えしておきます。特別なツールは使っていません。

迷子にならないための「開発フロー」

私がAIと開発計画を立ててみて、一番良かったのは「迷子にならず、見通しを立てることができたこと」です。AIと「次はこれをやろう」「この順番で進めよう」と対話しながら、開発の全体像を明確にしていきました。

この図は、私たちが話し合って決めた開発の進め方です（認識合わせしたドキュメントはMarkdown、Mermaid図をVS Codeの拡張機能「Markdown Preview Enhanced 」で可視化）。

AIと決めた開発フロー

この図のポイントは、それぞれのステップの間に「レビューとフィードバック」の矢印が戻っていること。これは、AIが何かを提案するたびに、私自身が確認し、フィードバックを与えていることを表しています。

このキャッチボールのおかげで、私は開発の途中で「あれ？何作ってたんだっけ？」と迷子になることがなくなりました。

AIが作る「人間が読める」ドキュメント

AIは、常にMarkdown形式のドキュメントを出力してくれます。これは、私たち人間が読みやすく、レビューしやすい形式です。

例えば、開発の最初のステップである「要件定義」では、AIがユーザーの要望を整理してrequirements.mdというファイルにまとめてくれます。そして、次の「概要設計」では、そのrequirements.mdを元に、アプリの骨組みをhigh_level_design.mdに書き出してくれました。

AIが作ったドキュメントが、次のAIの仕事の「インプット」になる。 このように、AIと私が同じ「共通言語」を使って、共通認識を持ちながら、まるでペアプログラミングのように作業を進めていく。この感覚が本当に面白いんです。

まとめ：計画書は「共通言語」であり、未来の設計図

AIとの開発において、開発計画書は単なる書類ではありません。それは、AIと私をつなぐ共通言語であり、迷子にならないための未来の設計図なんです。

この進め方は、どんな小さなプロジェクトにも応用できます。AIと「どんな手順で進めるか」を話し合う自由度があるから、あなただけの開発スタイルをAIと一緒に見つけられるはずです。

次回は、いよいよこの計画書に基づいた具体的な設計書の中身を公開します。AIがどのような設計を提案してくるのか、そしてそのクオリティは？どうぞ、お楽しみに！

用語集

  • VS Code: Visual Studio Codeの略称。マイクロソフトが開発した、無料で使えるプログラミング用の高機能なテキストエディタです。
  • Gemini CLI: Command Line Interfaceの略。ターミナル上のコマンドラインから、Googleが提供する生成AI「Gemini」を利用するためのツールです。起動フォルダ以下の情報（プロジェクト内のソースなど）を把握させつつ、ターミナルでできる範囲で、AIエージェント（単純な回答だけなく、与えた目的に対して自律的に進めることが可能）として利用できます。基本的にgeminiに把握させたい内容を記載したgemini.mdを起動フォルダ配下に配置することで、geminiに継続して認識させることができます。
  • Markdown: 見出しや箇条書きなどを簡単な記号で記述できる、軽量なマークアップ言語です。開発者のドキュメント作成で広く使われています。生成AIでも理解、作成可能です。
  • Mermaid: テキストベースでフローチャートやシーケンス図などのグラフを作成できるツールです。Markdownファイル内にコードを埋め込むことで、視覚的な図を簡単に作成できます。生成AIでも理解、作成可能です。
  • Markdown Preview Enhanced: VS Codeの拡張機能の一つ。Markdownファイルをリアルタイムでプレビューでき、複雑な図表などもきれいに表示できます。

補足：詳細な開発計画書はこちら

プロジェクトサマリー
項目 内容
プロジェクト名 AIService
最終ゴール 生成AIを活用したアプリ開発の生産性を上げるための生成AIを利用するためのサービス機能を構築する
現在のフェーズ 計画
現在の状況 計画文書の最終化
フェーズ分けと工程定義

  • 1. 計画フェーズ

    • 1.1. 要件定義:
      • 完了条件: サービスの機能要件（例: AIモデル呼び出し、プロンプト生成）および非機能要件（例: 性能、セキュリティ）が定義され、合意されている。
    • 1.2. 概要設計:

  • 2. 開発フェーズ

    • 2.1. 外部設計:
      • 完了条件: 各サービスが提供するAPIのエンドポイント、リクエスト・レスポンスのデータ形式など、外部インターフェース仕様が定義されている。
    • 2.2. 詳細設計:
      • 完了条件: 各サービスの内部構造（クラス、モジュール、関数など）や、データベースのスキーマなどが具体的に設計されている。
    • 2.3. 製造・単体テスト:
      • 完了条件: 詳細設計に基づき実装が完了し、個々の機能（関数やクラス）が正常に動作することを単体テストで確認済みである。
    • 2.4. 連結テスト:
      • 完了条件: 複数のサービスを連携させた際に、APIリクエストからレスポンスまで、データが正しく受け渡され、意図通りに動作することを確認済みである。
    • 2.5. 総合テスト:
      • 完了条件: システム全体が要件定義を満たしていることを確認し、性能やセキュリティなどの非機能要件に関するテストも完了している。
インプット・アウトプット定義
工程 タスク名 インプット アウトプット アウトプット形式
1.1. 要件定義 機能・非機能要件の定義とドキュメント化 ・gemini.md
・ユーザー要求 		・要件定義書 ・requirements.md (Markdown)
要件定義レビュー ・requirements.md ・レビュー議事録 ・review_log.md に追記 (Markdown)
1.2. 概要設計 アーキテクチャとサービス構成の設計 ・requirements.md ・概要設計書
・総合テスト計画書 		・high_level_design.md (Markdown, Mermaid図含む)
・system_test_plan.md (Markdown)
概要設計レビュー ・high_level_design.md
・system_test_plan.md 		・レビュー議事録 ・review_log.md に追記
2.1. 外部設計 APIインターフェース仕様の定義 ・high_level_design.md ・外部設計書
・結合テスト計画書 		・api_spec.md (Markdown, OpenAPI/YAML形式)
・integration_test_plan.md (Markdown)
外部設計レビュー ・api_spec.md
・integration_test_plan.md 		・レビュー議事録 ・review_log.md に追記
2.2. 詳細設計 サービス内部構造の設計 ・api_spec.md ・詳細設計書
・単体テスト計画書 		・detailed_design.md (Markdown, Mermaid図含む)
・unit_test_plan.md (Markdown)
詳細設計レビュー ・detailed_design.md
・unit_test_plan.md 		・レビュー議事録 ・review_log.md に追記
2.3. 製造・単体テスト 各サービスの開発と単体テスト実施 ・detailed_design.md
・unit_test_plan.md 		・ソースコード
・単体テストコード
・テスト結果 		・.py 等のソースファイル
・test_*.py 等のテストファイル
・unit_test_report.md (Markdown)
製造・単体テストレビュー ・ソースコード
・テスト結果 		・レビュー議事録 ・review_log.md に追記
2.4. 連結テスト サービス間連携のテスト ・api_spec.md
・各サービス 		・連結テスト仕様書
・テスト結果 		・integration_test.md (Markdown)
連結テストレビュー ・integration_test.md ・レビュー議事録 ・review_log.md に追記
2.5. 総合テスト システム全体のテストと品質検証 ・requirements.md
・system_test_plan.md
・全サービス 		・総合テスト仕様書
・テスト結果 		・system_test.md (Markdown)
総合テストレビュー ・system_test.md ・レビュー議事録 ・review_log.md に追記
共通 開発フローの管理 ・development_plan.md ・開発フロー図 ・development_flow.md (Markdown, Mermaid図含む)

補足：詳細な開発フローはこちら

生成AIとの協調開発フロー図
graph TD
    subgraph "プロジェクト開始"
        A[gemini.md] --> B(AIによる計画提案)
    end

    subgraph "計画・設計フェーズ"
        B -- 開発計画書(development_plan.md) --> C(1.1. 要件定義)
        C -- 要件定義書(requirements.md) --> D(1.2. 概要設計)
        D -- 概要設計書(high_level_design.md), 総合テスト計画書(system_test_plan.md) --> E(2.1. 外部設計)
        E -- 外部設計書(api_spec.md), 結合テスト計画書(integration_test_plan.md) --> F(2.2. 詳細設計)
        F -- 詳細設計書(detailed_design.md), 単体テスト計画書(unit_test_plan.md) --> G(計画フェーズ完了)
    end

    subgraph "開発・テストフェーズ"
        G --> H(2.3. 製造・単体テスト)
        H -- ソースコード, 単体テスト結果 --> I(2.4. 連結テスト)
        I -- 連結テスト結果 --> J(2.5. 総合テスト)
        J -- 総合テスト結果 --> K(開発フェーズ完了)
    end

    subgraph "レビューとフィードバック"
        C -- レビュー --> B
        D -- レビュー --> C
        E -- レビュー --> D
        F -- レビュー --> E
        H -- レビュー --> F
        I -- レビュー --> H
        J -- レビュー --> I
    end

    subgraph "共通管理"
        L[progress_tracker.md]
        M[review_log.md]
        L -- æ›´æ–° --> C
        L -- æ›´æ–° --> D
        L -- æ›´æ–° --> E
        L -- æ›´æ–° --> F
        L -- æ›´æ–° --> H
        L -- æ›´æ–° --> I
        L -- æ›´æ–° --> J
        M -- 記録 --> C
        M -- 記録 --> D
        M -- 記録 --> E
        M -- 記録 --> F
        M -- 記録 --> H
        M -- 記録 --> I
        M -- 記録 --> J
    end