ワークフロー一覧

複数の AI プロンプトを順番につなぎ、1 つの作業を完了させる 24 本のワークフロー。

24AI ワークフロー

AIで週報を書く：書き直しにならない5ステップ週報が差し戻されるのは文章力の問題ではなく、上司に結果・リスク・判断してほしいことが伝わっていないからです。今週のチャットから事実を拾い、上司の視点で組み直し、判断を仰ぐ部分を切り出したうえで、型通りの言い回しを削り、数字を確認します。
会議を、実行できるアクションリストに変える方法会議のよくある結末は「話は盛り上がったのに、解散したら何も残らない」です。この手順では、発言を引用できる決定に整え、決定・担当・期限だけの議事録に削り、チェックできる手順に分解し、最後に担当のいない案件と他部署への依頼を切り出します。
素材の山から、構成の通った記事を書く方法素材が多いことは記事の良さではありません。長文の多くは文章ではなく構成で失敗します。この手順では、断片をまず主張の通った構成案に圧縮し、書いたあとに読者の視点で離脱地点を特定して構成を直し、言葉を整え、見出しを付けたうえで事実と数字を確認します。
自分の文章からAIっぽさを消す編集の順番AIっぽさは誤字ではなく、文の形・リズム・主張の立て方に表れます。この手順では、まず型通りの言い回しを削り、残った文を整え、次に主張の強さと根拠の強さを一文ずつ照合し、事実を確認し、最後に離脱する読者の視点で検収します。
まったく知らない分野に、2時間で入る方法知らない分野でいちばん危ないのは、いきなり細部に入ることです。この手順では、まず知識マップで全体がいくつの塊でできているか、何が何に依存するかを見て、用語を平易な言葉に置き換え、最小限の学習パスを切り、平易な説明で穴をあぶり出し、最後に誤解している箇所を探します。
論文を読み、信用できるかを判断する手順論文が読みにくいのは、多くの人が方法から読み、結論を最後に回すからです。この手順では、何を証明したのかを先に問い、議論の構造を描き、各主張の裏づけ・集計定義・因果推論を確認し、最後にその結論がどこまで使えるかを判断します。
技術面接で、深掘りに崩れないための準備暗記した答えは1問目しかもちません。この手順では、求人票から聞かれる質問を逆算し、実際のシステムを分解して設計問題に備え、技術判断ごとに「なぜ」を5回掘り、自分で説明して誤りを指摘させ、最後に実際の深掘りのリズムで模擬面接をします。
転職の経歴を、説得力のある物語にする方法面接で語るのは履歴ではなく、なぜそう選び、何を犠牲にし、何が起きたかです。この手順では、散らばった事実を一本の線に並べ、事実と推論を分け、主張ごとに根拠を付け、聞き手別に書き分け、最後に疑っている読者の視点で押します。
曖昧な要件をリリースまで進める手順曖昧な要件をリリースできる形にするまで、データモデル化、タスク分割、テストの穴埋め、影響範囲の確認、公開前の設定チェックの順に進めます。各ステップの成果物が次の入力になります。
本番障害が起きたとき、原因をどう絞り込むか本番でエラーが出たとき、最初の ERROR から推測を始めると遠回りになります。ログを時系列に並べ、証拠と推測を分け、最小の再現テストを書き、修正の影響範囲を確認してから、検証できる振り返りに残します。
誰も保守していない古いプロジェクトは、どこから見るか古いコードベースでは、理解しないまま変更することが最大のリスクです。まずコードとシステムの境界を読み、危険な箇所を特定し、テストの穴を埋め、依存関係の更新を評価してから、最初の一行を変えます。
ゼロから API を設計するとき、先に何を決めるかAPI に呼び出し元が付くと、変更はコーディングではなく調整になります。まず要件をデータモデルに落とし、設計の穴を突き、失敗時の挙動を決め、テストで契約を固定してから、並行実装に分けます。
コードレビューを書式の議論にしないために手順がないと、レビューは書式の議論になりがちです。作者がまず自分で見直し、テストで根拠を添え、レビュアーは影響範囲に応じて失敗経路と並行性を深く確認します。
データベース移行を失敗させない進め方移行のリスクはロック、切り戻し、更新し忘れたクエリに集まります。影響範囲を洗い出し、計画を一度否定してみてから、移行・切り戻し・検証を一式で書き、実際のクエリで確認します。
技術選定で、勘に頼らずに決めるには技術選定は早い段階で固定されがちです。同じ軸で候補を比べ、不可逆な部分を特定し、事前検証とコスト確認で実際の負担を洗い出し、開始前に退出条件を決めます。
最後まで読まれる技術文書の書き方技術文書が読まれないのは、情報量が足りないからではなく、読者の問いに答えていないからです。構成を組み、見出しで要点を示し、主張と根拠を突き合わせ、読者に合わせて書き直します。
デザインレビューの準備：1枚の要件から判断できる案まで1枚の要件と1版のデザイン案を、結論のあるレビューに変える進め方です。目的と境界を先に書き、自分で一度ダメ出しをし、最も突かれる質問を用意して臨み、通った結論を開発に渡します。
ひとつの思いつきを、画像生成で使えるプロンプトに仕上げる漠然とした思いつきから始めて、主題、構図、光、質感の順に変数をひとつずつ固定します。参照画像から語彙を借り、配色は一度だけ決め、再利用できるルールを書き残して、一連の画像が揃って見えるようにします。
UIコピーの書き方：ボタン、空状態、エラー表示画面の中で言葉が出る場所をすべて洗い出し、状態ごとに書きます。ボタンは動作を、空状態は次の一歩を、エラーは誰の問題かと再試行できるかを示します。最後に語調を揃え、新規と既存の利用者向けに一度ずつ書き直します。
二つの案から、あとで振り返れる決定を下す二つの案を同じ比較表に置き、それぞれの暗黙の前提を洗い出し、構造的に比べ、最後に自分が選びたいほうだけを攻撃します。終了条件と三か月後に確認することを書いて、決定を検証できる形にします。
計画をストレステストする：失敗した前提から考える計画の中で曖昧な点を先に書き出し、「すでに失敗した」ところから原因を逆算します。コスト見積もりを項目ごとに点検し、最も安く反証できる経路を見つけ、引き金となる兆候と退出条件を備えたリスク表に落とします。
AIの出力が使えるかどうかを見極めるまず事実、推論、好みを分け、前後の矛盾と出典を一件ずつ確認し、根拠が主張を支えているかを見ます。最後に反対役に攻撃させ、情報を運ばない言葉を削ります。
自分用のプロンプトテンプレート集をつくる直近二週間の実際の仕事から素材を集め、繰り返し現れるいくつかの型に分け、空欄付きのテンプレートにします。読み手と語調を変えて空欄の効き目を確かめ、余分な言葉を削って版を残します。
技術的な問題を、詳しくない人に伝えるまず専門用語なしで一度説明し、詰まった箇所を理解の穴として埋めます。専門用語を動作と結果に置き換え、限界を明示したたとえで支え、三文の版にし、最後に結論から報告します。