AIで作ったアプリで開発者と協働する方法

AIで作ったアプリで開発者と上手に協働するには、Gitリポジトリでコードを渡し、アプリの機能と目的を1ページにまとめ、完了の定義を含めて作業範囲を明確に書いた依頼を出します。どの部分を誰が変更するかを取り決め、あなたとAIが開発者の作業を上書きしないようにします。リポジトリとホスティングのアカウントはあなたの名義のままにし、秘密情報はメッセージではなく、適切な設定を通して共有してください。

AIでアプリの最初のバージョンを作り、その後に開発者を迎える人は多くいます。決済を追加したい、AIが何度やっても直せないものを直したい、セキュリティをレビューしたい、アプリが大きくなるにつれて引き継いでほしい、といった理由です。開発者を雇うかどうかまだ迷っているなら、開発者を雇うか、AIで作るかをご覧ください。このガイドは、すでに決めていて、協働をスムーズに進めたい人を想定しています。

開発者を迎える価値があるとき

よくある理由は次のとおりです。

• AIが解決できない問題。 明確な試行とロールバックを何度か繰り返しても、うまくいかないとき。
• リスクの高い領域。 決済、権限、機密データ、データベースの移行など。
• セキュリティやコードのレビュー。 公開前や、より大きな顧客を迎える前。
• パフォーマンス。 実際のトラフィックが来たとき。
• 成長。 アプリがビジネスになり、コードを所有する人が必要になったとき。

どれに当てはまるかを明確にしておくと、以下のすべてが決まりやすくなります。

ステップ1：コードを共有できる場所に置く

開発者はGitリポジトリで作業します。誰かに連絡する前に、次のことを行ってください。

1. プロジェクトを、プライベートなGitHub（または類似のサービス）のリポジトリに接続するか、エクスポートします。
2. コードや履歴に秘密情報が含まれていないことを確認します。APIキーを安全に保つ方法をご覧ください。
3. 新しいコピーからプロジェクトが動くかを確認します。セットアップ手順をAIに書いてもらいましょう。

このプロジェクトに参加する開発者向けにREADMEを書いてください。アプリの機能、技術スタック、ローカルでのインストールと実行方法、必要な環境変数（名前のみ）、フォルダ構成、壊れやすい点や特殊な点を含めてください。

Gitに慣れていない場合は、AIで作ったアプリでGitを使う方法で基本を解説しています。

ステップ2：1ページの概要を書く

開発者はあなたのチャット履歴を最初から見ていません。1ページで背景を伝えましょう。

• アプリの機能、対象者、利用している人数。
• 最も重要なこと：決して壊れてはならない流れ。
• 既知の問題と、すでに試したこと。
• 依頼する作業、そしてそれが完了したとどう判断するか。
• 制約：予算、期限、変えてほしくないもの。

良い「完了の定義」は、テストできるものです。例：「ログインしているユーザーは、Stripe Checkoutで月額プランを支払え、そのプランがアカウントページに表示され、カスタマーポータルで解約すると、期間の終わりにダウングレードされる。」「決済を何とかする」ではなく、こう書きます。

ステップ3：安全にアクセスを渡す

• コード： リポジトリの共同作業者として追加します。作業が始まったら、ZIPファイルをやり取りしないでください。
• ビルダー： AIアプリビルダーがチームメンバーに対応しているなら、このプロジェクトだけを含むワークスペースに招待します。
• 秘密情報： ホスティングサービスの設定に追加するか、パスワードマネージャーを通して共有します。キーをメールやチャットに貼り付けないでください。
• テスト用アカウント： 自分のログインを共有するのではなく、テストデータを使ったテスト用アカウントを作成します。
• 本番データ： 本当に必要な場合にのみ、必要な分だけ渡します。

リポジトリ、ドメイン、ホスティングのアカウントは、あなたの名義で保ってください。人を追加するのであって、アカウントを渡すのではありません。

ステップ4：誰が何を変更するかを決める

摩擦の最大の原因は、あなた（AIと一緒に）と開発者が、同じコードを同時に変更してしまうことです。ルールを1つ決めましょう。

どの方式を選んでも、指示を出すセッションの前には必ず最新のコードをpullし、大きな変更は、もう一方の人がレビューできるブランチで行ってください。

ステップ5：書面でやり取りする

• 問題は、手順、期待される結果、実際の結果を添えて報告します。良いバグレポートの書き方をご覧ください。
• 決定事項は1か所にまとめます。課題管理ツール、共有ドキュメント、プルリクエストのコメントのいずれかです。
• プルリクエストごとに、変更内容を平易な言葉で説明してもらいましょう。
• 進捗を確認する頻度を決めておきます。

ステップ6：作業をレビューする

レビューにコードを読める必要はありません。次の点を確認してください。

• 依頼どおりに動くか：プレビューまたはステージング環境で確認します。
• 他の部分が壊れていないか：重要な流れを実行して確かめます。
• 説明があるか：何をなぜ変更したかを説明してもらえているか。
• 秘密情報が入っていないか：コードに秘密情報が現れていないか。

より詳しく確認したい場合は、AIが生成したコードをレビューする方法にチェックリストがあります。人が書いたコードにも有効です。AIビルダーに、開発者のプルリクエストを平易な言葉で説明してもらうこともできます。

ステップ7：所有権を明確にする

• リポジトリ、ホスティング、ドメイン、サードパーティのアカウントは、あなたのものとして保ちます。
• 作業を始める前に、その人が書くコードの所有権を書面で取り決めます。契約の問題については、現地の法律を確認するか、専門家に相談してください。
• 作業が終わったら、その人のアクセス権を削除し、見られたキーを再発行します。

指示の例

前回のプルで、開発者がチェックアウトのコードを変更しました。何を変えたかを平易な言葉で説明し、アプリの他の部分がそれに依存しているかどうかを教えてください。

このアプリの中で最も複雑、またはリスクの高い部分を挙げてください。開発者にレビューの重点を伝えられるようにしたいです。

決済を開発者に任せます。今後は、src/payments配下のファイルや/api/billingのルートには触らないでください。変更が必要な場合は、私に知らせてください。

よくある間違い

• 依頼書がない。 開発者は、有料の時間を使って、あなたが望んでいたことを逆算することになります。
• 「バグを直して」「本番に出せる状態にして」のような、曖昧な範囲。
• pullせずに、両方が同時に編集する。 その結果、競合で作業が失われます。
• 自分のログインを共有する、またはチャットにキーを貼り付ける。
• アカウントが開発者の名義になっている。 別れることになったときに困ります。
• 作業の終了後にアクセス権を削除せず、キーを再発行しない。

チェックリスト

• コードはプライベートなリポジトリにあり、自分の名義で、秘密情報は含まれていない。
• READMEでセットアップを説明し、1ページの概要でアプリと作業内容を説明している。
• 作業には、テストできる完了の定義がある。
• アクセスは共同作業者の招待で、秘密情報は設定かパスワードマネージャーを通している。
• 誰が何を変更するかを取り決め、指示の前にpullしている。
• 作業は、概要と重要な流れに照らしてレビューしている。
• 所有権は書面で決め、作業が終わったらアクセスを削除してキーを再発行している。

Mythexでの開発者との協働

• ワークスペースに招待する。 オーナーは、座席ごとの料金なしで無制限の共同作業者を招待できます。メンバーはワークスペースのプロジェクトで作業します。このプロジェクトだけを見せるために、別のワークスペースを使ってください。公開済みアプリのクレジットは、ワークスペースのオーナーに請求されます。詳しくは招待をご覧ください。
• GitHub同期とエクスポート（Pro）。 リポジトリを接続してpush/pullするか、秘密情報を除いてプロジェクトをエクスポートできます。詳しくはGitHub、エクスポート、インポートをご覧ください。
• プレビューのリンクを共有する。 Mythexのアカウントを持たない人に、作業途中の内容を見せられます。終わったら削除してください。
• Askモード は、コードを変更せずにコードについての質問に答えます。開発者の変更内容を理解するのに便利です。

開発者がアプリを別の場所で動かす予定なら、AIで作ったアプリをエクスポートしてセルフホストする方法をご覧ください。

よくある質問