2025年、GeminiやAmazon Q Developer、Kiroを始めとしたコーディングエージェント（や他のAIを使ったサービスやツール）を自分も触るようになり開発の仕方にも変化が現れてきました🚀
それについて振り返ろうと思います。
AI導入当初：「ググる」に毛が生えたくらいの使い方🐣
コーディングエージェントとの当初の関わり方で自分がよくやっていたのが下記。
- 🐛「xxxってエラー出たんだけどこれ何？」（エラー分はコピペ）
- 🔄「Swiftでこう書いてたけど、Kotlinだとどう書くの？」
- 🧪「この関数作ったからテストコード書いといて」
- 📝「yyyyみたいな処理を書いてほしい」
もちろんこれらだけでも自身のタイピング量は減るし、ググる時間も減ってわかりやすくまとめてくれるので、作業時間が効率化されて便利です。
しかし、これらのAIの使い方は、あくまでコーディング作業の補助ツールという立ち位置が強いです。
そんなある日、チームでAIの使い方を共有しあった中で、他のメンバーが 「設計に迷ったとき、とりあえずAIに相談してる」 というのを耳にしました。
それまでは「正解」や「アウトプットがわかっているもの」を出力させることを考えていましたが、もっと手前の 「思考プロセス」の段階でAIを巻き込む ということを意識するようになりました。
使い方の変化 🔄
自分の実装について🧑💻
1. 実装前の「設計レビュー」
実装する前や実装途中で、
こういう実装をしようとしてるけど、現状のプロジェクトの設計思想的に外れたことしてない？
みたいに聞くことで、現状の設計を踏まえた実装方針を考えてくれたり、自分がこれからやろうとしていることがズレたことをしていないかを評価したり、改善のアドバイスをくれたりします。
2. レビューコメントの意図を深掘り
PRで自分がコメントのレビュアーの意図を解釈をできない場合も
hogehogeっていうコメントをもらったんだけど、どういう意味？
自分としてはhugahugaってことかと思ってるんだけどあってる？
みたいに聞くことで、指摘の意図を咀嚼して、的確な修正案を練れるようになりました。
これによって、相手の時間をいただいてわざわざ聞き直すみたいなことも減ったと思います。
（そもそも自分の読解力や知識を深めろよというツッコミは一旦棚に上げてます🙇）
こういった「思考の壁打ち」の流れを図にすると、以下のようになります。
開発効率改善に向けた検証で⚡️
PRレビュー依頼をSlackで毎回チームメンバーに手打ち入力で通知するのも面倒で、かつGitHub Appのsubscribeではできない表現で通知してレビュー依頼の地味な負荷を減らせないか？を考えたことがありました。
そんな時も調べるよりも前に相談。
💡 Geminiへの質問
GitHubでPRを作成して、Reviewersにメンバーをアサインした時をトリガーにしてSlackにアサインされたメンバーにメンションをつけて特定のチャンネルに通知する方法はある？
その時のメッセージの内容には誰からのレビュー依頼かと、PRのURL、期限（PRのコメントに記載あり）を含めたい。
🤖 Geminiの回答
はい、可能です。最も確実で柔軟な方法は GitHub Actions を使うことです。
Slack標準のGitHub連携機能でも通知は可能ですが、「アサインされたメンバーにSlack上でメンション（@mention）する」という要件を確実に満たすには、GitHub Actionsでワークフローを組むのが最適です。
1. GitHub Actionsを使用する方法（推奨）
これが最も強力で、要件を正確に満たす方法です。PRのレビューリクエストをトリガーに、指定したSlackチャンネルへ、アサインされた人のSlack IDを使ってメンション付きのメッセージを送信します。
// 省略
設定ステップ
ステップ1: Slackアプリの準備
1. Slack API にアクセスし、「Create New App」からアプリを作成します。
2. OAuth & Permissions に移動し、Bot Token Scopes に以下の権限を追加します。
・chat:write: チャンネルにメッセージを投稿するため
・users:read.email: メールアドレスでSlackユーザーを検索するため
// 省略
YAMLファイルの作成も（出力された最初の結果そのままを添付）
name: Notify Reviewer on Slack
on:
# プルリクエストのイベントで発火
pull_request:
# レビュアーがアサインされた時（またはチームがアサインされた時）
types: [review_requested]
jobs:
notify-slack:
runs-on: ubuntu-latest
steps:
# 1. アサインされたレビュアーのGitHubユーザー名を取得
- name: Get Reviewer's GitHub Username
id: get_username
run: echo "username=${{ github.event.requested_reviewer.login }}" >> $GITHUB_OUTPUT
# 2. GitHub APIを使い、ユーザー名から公開メールアドレスを取得
# (注意: ユーザーがGitHubプロフィールにメールアドレスを公開している必要があります)
- name: Get Reviewer's Email
id: get_email
run: |
EMAIL=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
"https://api.github.com/users/${{ steps.get_username.outputs.username }}" \
| jq -r .email)
echo "email=$EMAIL" >> $GITHUB_OUTPUT
# 3. Slack APIを使い、メールアドレスからSlackユーザーIDを取得
- name: Find Slack User by Email
id: find_user
run: |
SLACK_USER_ID=$(curl -s -X POST 'https://slack.com/api/users.lookupByEmail' \
-H 'Authorization: Bearer ${{ secrets.SLACK_BOT_TOKEN }}' \
-H 'Content-Type: application/json' \
-d '{"email": "${{ steps.get_email.outputs.email }}"}' \
| jq -r .user.id)
echo "id=$SLACK_USER_ID" >> $GITHUB_OUTPUT
# 4. Slackにメンション付きで通知を送信
- name: Send Slack Notification
uses: slackapi/slack-github-action@v1.24.0
with:
# ここにSlackチャンネルのID（Cから始まる英数字）を指定
channel-id: 'C012345ABC'
# <@SlackユーザーID> の形式でメンションする
slack-message: |
:eyes: レビューリクエストです！
*PR:* ${{ github.event.pull_request.html_url }}
*Reviewer:* <@${{ steps.find_user.outputs.id }}>
*Requestor:* ${{ github.actor }}
env:
SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
といった感じで、やりたいことは数秒でコードにまでしてくれるし設定手順までまとめてくれました。
そこからは
- メンション先をグループではなく、アサインされたメンバー本人になるように修正して欲しい。
- メールアドレス以外でメンションさせるような方法はある？
- PRのコメントからレビュー期限を抽出して、期限を通知メッセージ内に含めるようにしたい。
みたいに何度かやり取りをしながら実現に向けたコーディングを進めて、実働1時間かそこらで下記のようなSlack Appを作って検証を回すことができました。
プレゼン資料で📊
厳密にはコーディングではないが、社内での発表スライドとかにもAIを使うようになりました。
hogehoge〜ってこと言いたいんだけどプレゼンの構成考えて。
みたいに始めてAIに構成を練ってもらい、そこから出力してもらいます。
その後、その構成や内容をもとにまじん式スライドで作成してもらいました。
利用していた当初はv3でしたが、v4も出たみたいなので、見てみると良いかと思います。
また、最近だとNotebookLMのスライド作成機能もかなり見た目がイカしている感じで作ってくれたので、こちらもおすすめです✨
記事で🖊️
もちろんこの記事も構成や文章、図を作成してもらったりしています。
まだ文章にはAIっぽさみたいなのがあったので手直しする箇所もありましたが、結構便利に作れました。
ちなみに、本記事作成前に社内で今回の内容を発表する機会があり、その時に作成したスライドの内容を踏まえて記事にしています。（簡単な発表だったので、詳細な肉付けはこの記事からやっていますが）
気づき🧠
こういった使い方の変化が生まれたことで、問題解決やアウトプットまでのスピードが体感早まりました。
1. 「悩む時間」の短縮 ⏳
「どう設計しようか」「何から手をつけようか」と一人で画面の前で考える時間を消費していましたが、すぐにAIに「どう思う？」と投げかけるようにすることで悩む時間が減りました。
2. 検証・開発サイクルの加速 🏎️
手を動かす時間に充てられるようになったことで、検証やアウトプットを早く実行できるようになりました。 「すでにある問題」だけでなく、 「これからやりたいこと」 をAIに伝えて壁打ちすることで、初手の方針が定まりやすくなり、迷走することが減りました。
3. 「環境」も整える意識へ 🌍
AIが働く環境整備をすることで、アウトプットの質も高まると思いました。 rule用のmdファイルを整備するとかです。（なんならその内容自体もAIに作成して修正しちゃっても良いですね。）
4. 細部でも使ってみても良い 🔍
細かい作業でも「これAIに依頼・相談してみるか」と思うようになり、それによってアウトプットの速度が格段に上がりました。 あと早期に相談することで、自分が想定していなかった観点漏れにも気づきやすくなったりするので手戻りの確率も下げられると感じました。
これらを通して、成果やアウトプットが早く出力でき、質も上げられるなと感じました。
とはいえ、まだまだ道半ばだとも思うのでどんどん改善アクションも起こしていきたいです。
↑本記事の内容を踏まえた要約イラストも作ってもらいました。（一発でこれ。ちゃんと内容が反映されてすごい）
終わりに
経験をベースにした記事なのでテクニカル面が少し薄かったかもしれませんが、他職種の方にも応用できることかもしれませんので、AIの利用について参考になれば嬉しいです。
また、自分はこういう使い方してるよ！とかがあれば、そちらもぜひコメントや記事にして知見を共有いただければと思います。
みんなでもっともっとAIを使いこなしていきましょう🤩
※本記事はLIFULL Advent Calendar 2025のシリーズ2・16日目・生成AIカレンダー Advent Calendar 2025のシリーズ2・16日目の記事になります。
併せて他の方の記事もご覧ください。