1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI との共同作業をプロジェクトとして管理する仕組みを作った(設計書3点・非公開リポジトリ・記事素材)

1
Posted at

はじめに

AI エージェントと一緒に開発や構築を進めるようになって、最初に困ったのは「管理」でした。チャットで決めたことが流れてしまう、前に作ったものの設計意図が分からなくなる、同じ説明を何度もする。このあたりは人間同士の共同作業と同じで、仕組みで解決するしかありません。

そこで、AI との作業は原則すべて「プロジェクト」として管理するルールを決め、Google Drive と GitHub を置き場にした運用を始めました。この記事では、その標準セットと運用フローを紹介します。対象は「AI エージェントと長く付き合って、作ったものを資産として残したい」人です。

置き場の構成

  • Google Drive に「mese作業用」というフォルダを作り、プロジェクトごとにサブフォルダを切る
  • ルートに「プロジェクト一覧.md」を置き、全プロジェクトの状態・成果物・置き場所を1枚で把握できるようにする
  • コードがあるものは GitHub に非公開リポジトリを作る
  • ローカルの作業フォルダにも同じ構成を保持する

一覧には進行中だけでなく、完成・停止・保留も含めます。「止まっているものが見える」ことが大事で、たとえば本番導入を保留にした可視化ツールや、認証待ちで止まっているクラウド PC の構築なども、その理由ごと一覧に残っています。

成果物の標準(全プロジェクト共通)

プロジェクトを作ったら、まず次の標準セットを揃えます。

成果物 内容
概要説明書 目的・全体像・現在の状態
基本設計書 方針と構成の決定事項
詳細設計書 実装レベルの仕様、検証項目、未決事項
README 使い方と入口(GUI アプリなら画面スクリーンショットを埋め込む)
GitHub リポジトリ アプリ/プログラムは常に非公開(private)
記事素材 つまずき・エラー文そのまま・解決方法を随時追記

この標準にした理由は単純で、AI が文脈を失っても、ドキュメントを読めば続きから再開できるからです。設計書3点は人間向けであると同時に、セッションをまたぐ AI への「引き継ぎ書」として効いています。決定の経緯(例:「Electron は重いので Tauri にした」)まで書いておくと、AI が蒸し返しをしなくなります。

秘密情報の扱いも標準化しました。秘密は .env のみに置き、.env は必ず .gitignore に入れて、コミットも共有もしない。これは全プロジェクト共通の絶対ルールです。

「記事素材」を最初から貯める

特徴的なのが「記事素材」の運用です。作業中に起きたエラーは、メッセージをそのままコピーして、起きた時点で素材ファイルに追記します。画面やエラーのスクリーンショット、つまずいたポイントと解決方法も同様です。

狙いは2つあります。1つは、後で技術記事を書くときの一次資料になること。もう1つは、同じ AI が同じ問題に再会したときの再発防止メモになることです。実際、この素材から「エラーの原文が豊富な記事ネタ」がいくつも生まれています。

運用を始めてしばらく経ち、プロジェクトと日常の会話から記事化できそうなネタを洗い出したところ、18件ほど集まりました。下書きまで進んでいるものも複数あります(例:GPU のない VM にローカル LLM を常駐させた話、入口のない VM にリバーストンネルで SSH する話)。

何をプロジェクトにするか

線引きも決めています。基本的には、AI と一緒にやる作業はほぼ全てプロジェクト化します。技術実験やツールの構築はもちろん、手順書を作るような作業も対象です。例外は、単純な Web 検索と、その場限りのリマインダーくらいです。

理由は「後から記事にしたくなるのは、たいてい地味な実験や構築のほうだから」です。最初からプロジェクトとして素材を貯めておけば、記事化は「書く」ではなく「まとめる」作業になります。逆に、プロジェクト化しなかった作業は、素材がチャットの中に流れてしまい、二度と掘り起こせません。

続き作業の再開フロー

中断と再開が前提の進め方なので、再開手順も決めています。

  1. 「続き作業ある?」と聞かれたら、プロジェクト置き場の更新が新しい順に並べる
  2. 番号付きリストと、番号が一致する選択肢ボタンで提示する
  3. 選ばれたら、まず「どこまで進んで、どこで止まったか」を設計書と一覧から報告する
  4. その地点から再開する

「進捗を先に報告してから再開する」のは、地味ですが効きます。AI が勝手に前提を変えて進める事故が減りました。

月次レビュー

月に1回、プロジェクト一覧を見直す定期タスクを入れています。完了に見えるプロジェクトを番号付きで「これもう完了でいい?」と提示し、私が選んだものだけを old フォルダへ移して一覧を更新します。削除ではなく移動にしているのは、間違えても戻せるからです。

なお、置き場フォルダ内での作成・編集・移動は AI に任せてよいことにしていますが、削除だけは必ず私の明示的な承認が必要という線引きもルール化しました。効率と安全のバランスを取るための線です。

まとめ

  • AI との作業は「プロジェクト+設計書3点+記事素材」を標準セットにして管理する
  • 一覧で「止まっているもの」も見えるようにすると、再開コストが大きく下がる
  • 承認が必要な操作(削除・公開・購入)と任せてよい操作を先に分けておくと、毎回確認しなくて済む

AI エージェントは「よく覚えてくれる相棒」に見えますが、実際にはドキュメントに残したことしか引き継げません。残す仕組みを先に作っておくのが、長く付き合うコツだと思っています。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?