0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

チームのプロンプト力を上げるためにプロンプトのサマリのレビュー会をしてみた話

0
Last updated at Posted at 2026-07-12

この記事は Qiita Tech Festa 2026 の投稿記事になります。

はじめに

最近はどの開発現場でも LLM Agentを使うのが当たり前になってきました。しかし、「LLM Agentを使いこなせているか?」はかなり人による印象です。成果物のレビューを見てもLLM Agent が有効に使えているかどうかは差が大きくあるなと感じています。

本来的にはそういった差異を減らすために Agent Skills を活用するのだと思います。しかし、私の職場では以下の記事

に書いたように Agent Skills は他の人が使うように管理されておらず、という状態です。

そこで今回、新人教育的な意味合いも込めて、 チーム内で「他人のプロンプトの振り返り・見直し」を話し合うプロンプトレビュー会 を実施してみました。本記事では、その時の取り組みと、そこから見えてきた「プロンプトをうまく使えてそうな人・まだ慣れてなさそうな人の違い」について紹介します。

概要・前提条件

今回、プロンプトの振り返りには以下のツールを使用しました。

  • tokoroten/prompt-review
    • LLMとのやり取りの履歴をエクスポートし、レポートとして可視化してくれる Agent Skills です
    • このレポートを元に、チームメンバー同士で「普段どんなプロンプトを書いているか?」の話し合いをしました

開始当時、私とプロジェクトのメンバーで Claude Code のアカウントが付与されていない人がいたのでこのときは採用しませんでしたが、 「Claude Code のディフォルトコマンド」+「Claude の Artifact での共有」を使うとより相互レビューがしやすいかもしれません。

Skill のインストール

gh skill を使ってインストールしました。Skill が Claude Code での利用を前提としているディレクトリ構成なので、 --allow-hidden-dirs で対象を指定してインストールが必要でした。

gh skill install tokoroten/prompt-review \
   --allow-hidden-dirs .claude/skills/prompt-review

レポートに出力される内容

サンプルが作者のGist にあります。

このうちレビュー会でレビューするのは主に以下の内容です。

まず

  • 7 総合評価サマリー

で特に問題ないという話だったら、よいと評価されている内容を読み、定型化したものやよいテクニックがあれば共有で使えないかの話をします。

詳細については以下の項目を参照します。

  • 3 技術理解度マップ
  • 4 プロンプティング力の評価
  • 5 AI活用スタイル

ここの辺りで あくまで LLM Agent と協業している範囲 にはなりますが、理解度や良いところ/改善したらよいことについて確認しています。

また

  • 6 成長の軌跡と学習提案

についてはある程度使い慣れている人だと改善提案されてもあえてやっていないパターンもあるので参考にしたりしなかったりというところです。

本題・実装:プロンプトレビュー会で見えてきたこと

レビュー会を実施した結果、AIの使い方において「慣れている人」と「まだ慣れていない人」の間で、パターンの違いが出ていたような気がします。

1. 慣れている人のプロンプトパターン

慣れている人のレポートは、以下のような特徴がありました。

  • 指示が具体的である
  • コンテキストの外部化と共通化ができている
    • 何度も同じ前提条件を書くのではなく、一定共通化できる内容はプロジェクトの AGENTS.md(カスタムルール)に逃したり、ワークフローを Skills にまとめたりと、LLMのコンテキスト管理をシステム的に行っている

2. まだ慣れていない人のプロンプトパターン

一方で、他のメンバー(特に新人層)のレポートを見ると、以下のような使い方が多く見受けられました。

  • 指示に「曖昧さ」が多い
    • 前提条件が抜けているため、期待からずれた回答が返ってきてしまい、同じ内容について何度も聞き直しが発生している
  • エラー時のコンテキストや「仮説」が不足している
    • エラーが出た際に、エラーログだけを貼り付ける、いわゆる 「丸投げ」 状態になっている
    • 「自分はこう考えているがどうか?」といった仮説や、実行環境のコンテキストが不足しているため、AIが的外れな解決策を提示し、結果としてやり取りのターン数が無駄に増えてしまっていた

エラー時に自分の仮説を与えることは「間違ったアンカリング(偏見)」をAIに与えてしまうリスクもあるため、必ずしも常に良いわけではありません。

しかし、何も情報を与えずに進めるよりは有意義になるディスカッションなることが多い印象です

おわりに

コードレビューと同じように、 「プロンプトもレビューする機会」 を作ることで、チーム全体の生産性の底上げに繋がるのではないかと思いました。その他にも新人教育で 分かっていない箇所の洗い出し にも役に立つ気がしています。

「全ログを取得して何かしたい」といった話は定期的に出るのですが、コストや運用の点で自社向けにログ基盤を使えない立場としてはファイル置いてるだけになっているのを見かけているので、こういった定期的なサマリの作成と振り返りの機会を設けることで改善につなげられないかと考えています。

0
1
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
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?