KPTとは？振り返りの進め方・テンプレート・具体例【2026年版】

プロジェクトの節目やスプリントの終わりに「振り返りをやりましょう」と集まったものの、良かった点の発表会で終わってしまった。反省点を並べたのに、翌月も同じ問題で詰まっている。振り返り会議には、そんな「やった感だけが残る」失敗がつきものです。

KPTは、この失敗を構造的に防ぐために生まれた振り返りフレームワークです。話す内容をKeep（続けること）、Problem（問題）、Try（次に試すこと）の3つに分けるだけというシンプルさで、開発チームの定番手法から、営業・マーケティング・バックオフィスまで広く使われるようになりました。

本記事では、KPTとは何かという基本から、実際の会議の進め方、そのままコピーして使えるテンプレート、ありがちな形骸化のパターンと対策、そして振り返りの記録と宿題管理をAIで自動化する方法までをまとめます。

⚠️ 本記事は、2026年7月時点の公開情報やユーザーフィードバックを基に独自にまとめたものです。

目次

1. KPTとは？
2. KPTのやり方：基本の5ステップ
3. そのまま使えるKPTテンプレート
4. KPTの具体例
5. KPTが形骸化する5つのパターンと対策
6. KPT以外の振り返り手法との使い分け
7. 初回のKPTを成功させる導入チェックリスト
8. 振り返りの記録をAIで自動化する
9. よくある質問（FAQ）
10. まとめ

KPTとは？

KPT（ケーピーティー）とは、仕事の進め方をKeep・Problem・Tryの3つの観点で整理する振り返りフレームワークです。 それぞれの観点は次の問いに対応します。

• Keep：うまくいったので、これからも続けたいことは何か
• Problem：問題だったこと、うまくいかなかったことは何か
• Try：次の期間で新しく試すこと、変えることは何か

もともとはアジャイル開発のレトロスペクティブ（スプリントの振り返り会議）で広まった手法ですが、構造が業種を選ばないため、現在では営業チームの月次振り返り、プロジェクトの節目のレビュー、個人の週次振り返りまで、幅広く使われています。

KPTの本質は、3つの箱に分けること自体ではありません。「感想」で終わりがちな振り返りを、「次のアクション（Try）」まで強制的に運ぶことにあります。KeepとProblemはあくまで材料であり、成果物はTryです。ここを押さえておくと、後述する形骸化のほとんどを防げます。

KPTとPDCAの違い

KPTとよく並べられるのがPDCAです。両者は競合するものではなく、粒度が違います。

PDCAでいうCheckとActionの部分を、チームの会議として具体的に実行する方法がKPTだと捉えると分かりやすいです。「PDCAを回そう」という掛け声だけでは回らなかったチームが、隔週のKPTを固定予定にしたら回り始めた、というのはよくある話です。

KPTのやり方：基本の5ステップ

KPTの会議は、30〜60分を目安に次の5ステップで進めます。ここでは6人までのチームを想定します。

ステップ1：前提を揃える（5分）。 振り返りの対象期間と範囲を最初に宣言します。「今回は直近2週間のリリース作業が対象」のように区切ると、話が発散しません。あわせて「人ではなく、仕事の進め方を対象にする」ことを毎回確認します。犯人探しが始まった瞬間に、振り返りは機能を停止します。

ステップ2：Keepを書き出す（10分）。 まず各自が数分で付箋や共有ドキュメントにKeepを書き出し、その後1人ずつ共有します。先に書いてから話すのがポイントです。いきなり発言形式にすると、声の大きい人の意見に引っ張られ、静かなメンバーの観察が出てきません。

ステップ3：Problemを書き出す（15分）。 同じ要領でProblemを集めます。ここで重要なのは、Problemを「事実」として書くことです。「コミュニケーションが悪い」ではなく「仕様変更が実装開始後に2回伝わってきた」と書けば、次のTryが具体的になります。

ステップ4：Tryを決める（15分）。 出てきたProblemの中から、影響が大きいものを2〜3個選び、それぞれに対するTryを議論します。Tryは「気をつける」「意識する」を禁止ワードにして、行動として書ける形に落とします。「仕様変更は必ずチケット化し、実装中の変更は翌スプリント扱いにする」のように、やったかどうかを後から判定できる粒度が理想です。

ステップ5：担当と期限を付けて閉じる（5分）。 決まったTryに担当者と確認タイミングを付け、次回のKPTの冒頭で結果を確認することを宣言して終了します。この「次回冒頭でのTry確認」こそが、KPTを回すエンジンです。

そのまま使えるKPTテンプレート

以下を共有ドキュメントやホワイトボードツールにコピーすれば、すぐに始められます。

# KPT振り返り ― [チーム/プロジェクト名] ― [日付]
対象期間: [YYYY/MM/DD 〜 YYYY/MM/DD]
参加者: [名前]

## 前回のTryの結果確認
- [ ] [前回のTry] ― 結果: [うまくいった / 続ける / やめる]

## Keep（続けること）
- [うまくいったこと、続けたい習慣]

## Problem（問題だったこと）
- [事実ベースで。いつ、何が、どう困ったか]

## Try（次に試すこと）※2〜3個まで
- [ ] [行動として書けるTry] ― 担当: [名前] ― 確認: [次回KPT]

## 次回KPT: [日付]

運用のポイントは3つです。

• 「前回のTryの結果確認」を一番上に置く。 KPTが1回きりのイベントではなく、続き物であることをフォーマット自体で保証します。
• Tryの数を2〜3個に制限する。 10個のTryは1個も実行されません。少なく決めて確実に回すほうが、チームの改善速度は上がります。
• Problemの箇条書きに「いつ・何が」を入れる。 事実で書く習慣がつくと、Tryの質が一段変わります。

KPTの具体例

イメージが湧くように、2つのチームの実例を挙げます。

開発チームのスプリント振り返り（2週間スプリント）

• Keep：朝会を15分で切り上げるルールが定着し、午前の集中時間が増えた／レビュー依頼に「背景」欄を付けたことで、レビュー往復が減った
• Problem：スプリント3日目に仕様変更が口頭で伝わり、2人が古い仕様のまま実装していた／リリース前日にステージング環境が他チームと競合した
• Try：仕様変更はチケット化されるまで実装に反映しない（担当：PM、次回確認）／ステージング利用をカレンダーで予約制にする（担当：インフラ担当、次回確認）

営業チームの月次振り返り

• Keep：商談の翌日に議事録を送る運用で、返信率が体感で上がった／デモを前半15分に移した構成が好評だった
• Problem：失注理由が「価格」とだけ記録され、実際は導入時期の問題だったケースが混ざっていた／商談メモの粒度が人によってバラバラで、引き継ぎに時間がかかった
• Try：失注理由を選択式＋一言コメントに変更する（担当：営業企画、次回確認）／商談メモのテンプレートを統一する（担当：リーダー、次回確認）

どちらの例でも、Problemが事実で書かれているため、Tryが「気をつける」ではなく仕組みの変更になっている点に注目してください。

KPTが形骸化する5つのパターンと対策

KPTはシンプルなだけに、形だけ真似て失敗するパターンも定番化しています。

• Tryが実行されない。 最多の失敗です。原因はほぼ「担当と確認タイミングがない」こと。テンプレートの冒頭に前回Tryの確認欄を置き、次回の会議で必ず結果を見る運用にします。
• Problemが人への不満になる。 「Aさんの返信が遅い」はProblemではなく攻撃です。「レビュー待ちで平均2日止まった」と事実に言い換えるようファシリテーターが促します。対象は常に人ではなく進め方です。
• Keepが世間話で終わる。 Keepは褒め合いの時間ではなく、「再現したい行動」を特定する時間です。「なぜうまくいったのか」を一言添えるだけで、Keepが資産になります。
• 毎回同じProblemが出る。 2回連続で同じProblemが出たら、それはTryの設計が浅いサインです。「もっと頑張る」系のTryを禁止し、プロセスか仕組みを変えるTryに絞ります。
• 記録が残らず、積み上がらない。 議事録係を立てると、その人だけ議論に参加できません。かといって記録ゼロでは、前回のTryの確認ができず、KPTが毎回リセットされます。この記録問題は後述のAI活用で解決できます。

KPT以外の振り返り手法との使い分け

KPTが常に最適とは限りません。代表的な手法と使い分けの目安をまとめます。

実務的なおすすめは、定例の振り返りはKPTで固定し、四半期や大きな節目だけタイムライン形式を挟む運用です。フォーマットを頻繁に変えると、チームが形式に慣れるコストばかりかかります。

初回のKPTを成功させる導入チェックリスト

KPTの導入でつまずくのは、たいてい1回目です。初回の体験が「面倒な会議が増えた」になると、2回目はもう開かれません。最初の1回の前に、次の8項目を確認してください。

• 対象期間を2週間以内に区切ったか（長すぎると記憶が薄れ、感想戦になります）
• 参加者を6人以下に絞ったか（多い場合はチーム単位に分割します）
• 書き出し用の共有ドキュメントかホワイトボードを事前に用意したか
• 冒頭で「人ではなく進め方を対象にする」と宣言する段取りがあるか
• 「先に書いてから話す」進行をファシリテーターが理解しているか
• Tryを2〜3個に絞るルールを共有したか
• Tryに担当と確認タイミングを付ける欄がテンプレートにあるか
• 次回のKPTの日程を、初回のうちにカレンダーに入れる準備があるか

もう1つ、導入初期に効くコツがあります。最初の2回は、Problemより先にKeepを厚めに扱ってください。 振り返りに慣れていないチームは、Problemから入ると防御的になります。「うまくいったことにも構造がある」という体験を先に作ると、3回目以降のProblemの議論が驚くほど率直になります。

なお、KPTはチーム専用の手法ではありません。週の終わりに1人で15分、今週のKeep・Problem・Tryを書き出す個人運用も効果的です。チーム導入の前に自分で1〜2週回してみると、ファシリテーションの勘所が体感できます。

振り返りの記録をAIで自動化する

KPTの運用で最後まで残る課題が記録です。ホワイトボードの付箋は撮影しても検索できず、議事録係を立てれば1人が議論から抜けます。そして前回のTryが確認できないKPTは、ただの雑談会に戻っていきます。

ここで効くのが、リアルタイムのAI会議アシスタントです。SuperInternは、PCのデバイス音声から直接会議を記録するボットレスのデスクトップアプリ（Mac/Windows対応）です。会議にボットが参加しないため、Zoom・Google Meet・Microsoft Teams・Webexのどれで振り返りをしても、また会議室に集まる対面のKPTでも、同じように動作します。

KPTでの使い方は具体的です。

• AIキャンバス（AI Canvas）にKPTのフォーマットを一度だけ登録する。 「これはKPT形式の振り返り会議。Keep、Problem、Tryを分類して記録し、Tryには担当者を付ける。前回Tryの結果確認も記録する」と指定すれば、以降の振り返りはこの構造のままリアルタイムで書き上がっていきます。

• 全員が議論に集中できる。 書記が不要になるので、付箋の転記やドキュメント清書という振り返り後の作業がそのまま消えます。
• Tryが発言と同時に記録される。 「じゃあ次スプリントはチケット化を必須にしよう」という一言が、その場で担当付きのTryとしてノートに載ります。
• 前回のTry確認が一瞬で終わる。 前回のKPTノートを開けば、決めたTryと担当が残っています。会議横断のAIチャットに「直近3回のKPTで決めたTryと、繰り返し出ているProblemを一覧にして」と聞くこともできます。
• 多言語チームの振り返りにも対応。 50以上の言語をリアルタイム翻訳できるので、海外拠点を交えたKPTでも、要約は自分の言語で受け取れます。

正直な注意点も書いておくと、SuperInternはライブの会議とそのノートに特化したデスクトップアプリで、付箋を並べるホワイトボードツールや、タスク管理ツールの代替ではありません。多くのチームは、決まったTryをSuperIntern MCP経由でClaudeなどのエージェントと接続し、LinearやJiraのチケットに起こす使い方をしています。無料プランがあるので、次回の振り返りから試すコストはかかりません。

よくある質問（FAQ）

KPTは何の略ですか？読み方は？

Keep（続けること）、Problem（問題）、Try（次に試すこと）の頭文字で、読み方は「ケーピーティー」が一般的です。「ケプト」と呼ばれることもあります。

KPTとPDCAの違いは何ですか？

PDCAは計画から改善までの業務サイクル全体を指す考え方で、KPTはそのCheckとActionを会議として具体的に実行するためのフォーマットです。対立するものではなく、KPTはPDCAを現場で回すための道具と捉えるのが実務的です。

KPTはどのくらいの頻度でやるべきですか？

開発チームならスプリントごと（1〜2週間に1回）、それ以外のチームなら隔週〜月次が目安です。頻度よりも「前回のTryを次回冒頭で必ず確認する」継続性のほうが重要です。四半期に1回だけの長時間KPTは、記憶が薄れて事実ベースの議論ができなくなるため、おすすめしません。

KPTの会議時間はどのくらいが適切ですか？

6人までのチームなら30〜60分が目安です。60分を超える場合は、対象期間が長すぎるか、Problemの議論がTryの設計ではなく原因の追及に流れているサインです。

リモートでKPTをやるにはどうすればよいですか？

共有ドキュメントやオンラインホワイトボードに書き出す時間を先に取り、その後に議論する流れは対面と同じです。リモートの場合は記録が画面上に残るぶん、議事録の自動化との相性がむしろ良く、SuperInternのようなボットレスのAIノートを併用すれば、書記なしで発言もTryも記録に残せます。

KPT分析という言葉も見かけますが、KPTと違うものですか？

同じものを指していることがほとんどです。振り返り会議の文脈では「KPT」「KPT法」「KPT分析」はいずれもKeep・Problem・Tryのフレームワークを意味します。

まとめ

KPTは、振り返りを「感想の共有」から「次の行動の決定」に変えるための、最小限で強力なフォーマットです。成功の条件は難しくありません。Problemを事実で書く、Tryを2〜3個に絞って行動の形にする、担当と確認タイミングを付ける、そして前回のTryを次回の冒頭で必ず確認する。この4つを守るだけで、振り返りは確実に積み上がり始めます。

そして、その積み上げを支える記録は、もう人間が手で作る必要はありません。ボットレスのAIアシスタントにKPTのフォーマットを一度教えれば、毎回の振り返りが構造化されたノートとして自動で残り、チームは本来の仕事である「議論して、変える」に集中できます。

SuperInternを無料で試す ― 会議にボットは入れず、KPTのフォーマットどおりにライブノートを自動作成。決めたTryを次の振り返りまで確実に持ち越せます。