はじめに
前回は、GitHub Copilotと“協働”してアプリ開発を進める体験や、AIを「優秀な若手エンジニア部下」として活用するコツを紹介しました。
第2回となる今回は、AIを開発パートナーとして最大限に活用するための「伝わる指示（プロンプト）」の工夫について、実際のやりとりを交えながらお伝えします。
※本文中のスクリプトやGitHub Copilotの回答は実際の開発時のものを抜粋して記載していますが、このまま書いても同じ回答が得られるとは限りません。ご了承ください。
※[開発者]はWebアプリの開発経験は豊富ですが、Flutterによるモバイルアプリ開発は初めての開発者です。
※本連載はAI利用の実体験にフォーカスしているため、Flutterなど技術的な詳細説明は省略しています。
指示は明確＆シンプルに。箇条書き・短文のすすめ
（ちょっと複雑な処理を追加したいけど、うまく伝わるかな…）
合計費用をLine311で表示したいです。
1. 合計費用を取得する
2. 自国通貨から通貨記号へ変換する（例：JPY→\）
3. 変換した通貨記号を合計費用の先頭に表示する
以下のように修正することで、Line311に旅行の合計費用を自国通貨の通貨記号付きで表示できます。
修正手順
--- 実際のソースコードのどこに修正をするか ---
修正コード
--- 修正後のソースコード ---
修正の動作
--- 修正部分のソースコードの説明 ---
テスト手順
--- テストするための手順 ---
最初は長文で説明しがちでしたが、AIは「箇条書き」「短文」のほうが意図を正確に汲み取りやすいと感じました。
要件や希望を細かく分けて（この例では開発者が要件を3文に分けて伝えています）伝えることで、Copilotの回答も整理されて分かりやすくなります。
長文日本語の“罠”と工夫
（つい一文に色々詰め込んでしまった…）
ユーザーがイベントの一覧画面で画像をタップしたら、その画像の表示画面に遷移しつつ、もし画像が見つからなかった場合はエラー画像を表示して、画像の表示画面では戻るボタンで元の画面に戻れるようにしたいです。
--- 回答が一部抜けていたり、期待と違う提案が返ってくることも ---
- 日本語は特に一文が長くなりがちで、「何を一番やりたいのか」がAIに伝わりにくくなることが多くなります。
- そんなときは、下記のように細かく分けて書き直すと改善されました。
- イベントの画像をタップしたらファイル表示画面に遷移する
- 画像が見つからなかった場合、エラー画像を表示
- 画像表示画面の戻るボタンでイベントの一覧画面に戻る
- このように、1つずつタスクを分けて伝えるのがポイントです。
AIと一緒に実装方針まで詰めることで精度UP
（複雑な機能追加だからなぁ、、いきなり「コードを書いて」と頼むのじゃなくて、まずは実装方針から相談したほうが良いよなぁ。。）
Import機能を実装します。Importはファイル一覧画面でファイルを追加した際、tps拡張子のファイルの場合にImport機能を発動させたいと考えています。まずは要件を整理してください。まだ、ソースコードの修正は実施しません。
ご提案いただいたユーザー要件について、以下の点を考慮して検討します。
現在のユーザー要件：
--- ユーザー要件について箇条書き --
検討ポイント：
1. ユーザーの操作フロー：
--- 検討すべきポイントの箇条書き --
改善提案：
--- 具体的な要件に対する改善案およびユーザー要件の修正案 --
次のステップ：
--- 実装準備などへの案内 --
この修正案がユーザー要件に合致しているかどうか、ご確認いただけますでしょうか？
（やっと要件の認識が合った。）
確認ありがとうございます。要件が整理されたところで、実装に向けたステップを検討してください。
インポートの機能の実装に向けたステップを以下に整理します。これにより、実装の流れが明確になり、効率的に進めることができます。
実装ステップ
--- 実装ステップの箇条書き --
実装に向けた準備
--- 実装に向け、ファイルの準備や既存ロジックの活用検討など --
実装の流れ
--- ユーザー要件に対する実装の流れ --
まとめ
--- 実装方針に関する有用性、サマリ --
この方針で問題ないかご確認いただけますでしょうか？
- ユーザー要件から相談することで、AIの出してくれる案が的確になり、誤った方向に進みにくくなります。
- 上流工程を少々時間がかかってもしっかり詰める事で、実装がスムーズに進みます。
- また、方針が合っているか途中で人間がチェックできるため、品質も担保できます。
コーディング規約の共有で品質を担保
以下のコーディングガイドラインに則ってソースコードの見直しをしてください。
コーディングガイドライン
1. 命名規則
1.1 変数名とフィールド名
- アプリケーション内の変数名には**キャメルケース**を使用します。
- 例: `startDate`, `endDate`, `userId`
- データベースのフィールド名には**スネークケース**を使用します。
- 例: `start_date`, `end_date`, `user_id`
1.2 クラス名
- パスカルケースを使用します。
- 例: `Trip`, `Itinerary`, `FileService`
1.3 定数名
- 全て大文字で、単語間をアンダースコアで区切ります。
- 例: `MAX_FILE_SIZE`, `DEFAULT_TIMEOUT`
2. ファイルとディレクトリの構造
--- 省略 ---
--- コーディング規約・ルールに沿ったソースコードの修正案を提示 ---
プロジェクトごとにルールやコーディング規約をコピペして伝えることで、AIもそれに合わせたコードを提案してくれます。
ただし、会話が長くなると規約を忘れてしまうこともあるため、要所要所で改めて規約を伝えると良いです。
初歩的・恥ずかしいレベルの質問こそレベルアップのチャンス
（うーん、、Fliutterの基本的な部分が理解できていない気がする。。他の人に聞くのも恥ずかしいから、AIに教えてもらっちゃおう。）
Flutterで“Future”と“Stream”の違いが分かりません。
それぞれどんな場面で使うのが良いでしょうか？
- Future：1回だけ値を返す非同期処理（例：ファイル読み込み、APIリクエストなど）
- Stream：複数回値を返す非同期処理（例：データの逐次受信、ユーザー入力監視など）
「今さらこんなこと聞いていいのかな？」と思うような質問も、AIなら気軽にできます。
その結果、自分の理解の穴や基礎を埋め直すことができ、結果として開発レベルの底上げにつながりました。
おわりに
今回は、伝わる“プロンプト”のコツや、AIとの会話で意識したいポイントを紹介しました。
AIを理解していくことで、AIに伝わるプロンプトもより洗練されていくと思います。
これは、人とのコミュニケーションにも通じるものがありますね。
最後までお読みいただきありがとうございました。
次回は、AIにコードを書かせるとき・修正するときの現場テクニックについて、さらに具体的な事例と共に掘り下げていきます。
※本記事は当社による2025年のモバイルアプリ開発実体験を元に記載しています。日々、GitHub CopilotおよびAIエンジンは進化しているため、最新の状況とは異なる場合もあります。もっと良い活用方法があるかもしれませんが、あくまで一つの事例としてお読みいただけますと幸いです。
TravelPassportアプリは以下からダウンロードできます。
