はじめに こんにちは。グループIT推進本部の鷹雄です。 Codex Ambassadorとして、社内 ...

現在、FinOps プラクティショナーは増え続ける AI ツール群を利用できるようになりました。しかし、それぞれのユースケースに適したツールを組み合わせることこそが、プラクティスを加速させるか、不要な複雑さを持ち込むかの分かれ目になります。AWS は、AI ラインナップの各ツールを、それぞれ異なるコンテキストと異なる種類の作業に向けて設計しています。このブログでは、5 つのツールについての実践的な整理、それぞれをいつ使うべきか、そしてなぜそれが FinOps にとって重要なのかを説明します。 ここで重要なのは、ある仕事をこなせるツールと、専用のツールとの間には意味のある違いがあるという点です。 AWS FinOps Agent は、Cost Optimization Hub および AWS のコストと使用状況データとのネイティブなインテグレーションを備えたフルマネージドソリューションであり、精選され、検証されたインサイトを提供します。このブログで説明されている他のアプローチは、追加の設定やデータ接続が必要であり、マネージドソリューションが持つ深さ、精度、運用面での即応性には及ばない場合があります。最適な選択肢を選ぶ際には、これらのトレードオフを自社の要件と照らし合わせて評価することが重要です。 FinOps プラクティショナーはどのような AI ツールを利用できるか？ AWS FinOps Agent Amazon Quick Kiro Amazon Q （In Console） AWS DevOps Agent それぞれのツールについて、その中核となる目的と理想的なユースケースを見ていきます。 AWS FinOps Agent AWS FinOps Agent とは：コスト異常を根本原因まで調査し、組織全体のコストに関する質問に答え、すでに使用している Jira や Slack などのツール上に直接インサイトを届ける、エージェント型 AI ソリューション（現在パブリックプレビュー中）です。 FinOps Agent をいつ使うのか： コスト異常調査： コストのスパイクを関連付けて根本原因と責任者を特定し、オーナーチーム宛の Jira チケットまたは Slack メッセージを作成するのに役立ちます。 自然言語によるコスト問い合わせ： エンジニアが「先月支出が増えたのはなぜですか？」といった質問をして、FinOps チームの関与を必要とせずに、実際の AWS Cost Explore r データに基づいた回答を得られるようにします。 定期的なコストレポート ：ステークホルダーごとに内容を調整したレポートを、そのままプレゼンテーションに使える形式（HTML、PDF、PPT）で、設定したスケジュール（日次／週次／月次）に従って生成します。 最適化の推奨事項 ： AWS Cost Optimization Hub と AWS Compute Optimizer から節約機会を取得し、エンジニアリングチームがすぐに着手できる Jira チケットとしてまとめます。 Amazon Quick Amazon Quick とは：既存のデータソースやツールに接続する、AI を活用したデスクトップおよび Web サイトのコンパニオンです。FinOps にとっての価値は、プラクティショナーがターミナルに触れることもコードを書くこともなく、コストデータ、ダッシュボード、ワークフローに対する会話型のインターフェースを得られる点にあります。 コストデータに接続する方法は 2 つあります。Billing Cost Management MCP (Model Context Protocol) を介して AWS Cost Explorer やその他の請求 API に接続すると、状況に応じたリアルタイムの回答が得られます。一般的なチャットボットの応答ではありません。自社のアカウント、自社のデータ、自社の数値です。あるいは、複数の Payer を持つ組織で Amazon Quick dashboards (CUDOS/CID) を導入している場合は、 Quick Spaces を使用してそこから支出データをクエリできます。CUDOS と組み合わせて Quick を使用する方法については、こちらの ガイド を参照してください。結果が得られたら、それを Slack、メール、その他の ツール に接続して、テキスト、PPT、または必要な形式で関連付けて共有できます。 Quick は、再利用可能なスキル（平易な言葉で記述できる、自動化された多段階のワークフロー）、インタラクティブなアプリ（計算ツール、モデリングツール、数秒で作成できるダッシュボード）、そしてスケジュール実行される監視（毎日のコスト異常ダイジェストを毎朝フィードに配信）をサポートしています。 FinOps で Amazon Quick をいつ使うのか： 「X はいくらかかりますか？」という質問にその場で回答 （料金の確認、サービス比較、影響のモデリング） 複数の Payer をまたいだクエリ： 実際の AWS コストデータに会話形式で問い合わせ（「今月と先月のコスト要因の上位 5 つ」） 手動で掘り下げる代わりに、 Amazon Quick のダッシュボード上の数値について「なぜ」を質問 スキル作成： アカウントのビジネスコンテキストを使用して、チームメイトからのコストに関する質問への回答を自動化 定期的なレポートの自動化： エグゼクティブサマリー、タグ付けコンプライアンス、チャージバックの配分 その場で軽量 アプリ を構築 （Savings Plan の損益分岐点計算ツール、予算バーンレートトラッカー） ステークホルダー向けコミュニケーションのドラフト作成： 責任追及しないコスト通知、エグゼクティブサマリー、トレーニング資料 Kiro Kiro とは：ユーザーと並んで自律的にコードの記述、読み取り、変更を行うエージェント型 IDE です。FinOps にとっての価値は、コーディングを高速化できることだけではありません。何かをデプロイする前に、開発ワークフローにコスト意識を組み込めることです。Kiro は、実装の時点でコストの問題を捉えてシフトレフトすることを支援します。そのために  Kiro Cost Optimization Power  が役立ちます。Kiro Power は、MCP、コストのベストプラクティスを含むステアリングファイル、最適化の機会を自動化するためのフックをまとめたものです。詳細は、動画「 Kiro for Cost Optimization: Agentic AI for FinOps 」をご確認ください。 FinOps で Kiro をいつ使うのか： Infrastructure as Code の構築または変更： Terraform または CDK で構築する際、作業を進めるうちに Kiro が高価なリソースの選択肢にフラグを立て、より安価な代替案（適切なサイズのインスタンス、Graviton、gp2 ではなく gp3）を提案します。 コスト見積もりの生成： Kiro に IaC を分析させ、デプロイ前に毎月の予測コスト内訳を作成してもらうと、計画段階で想定外の出費に気づけます。 Cost Optimization Hub の推奨事項をコードに変える： 推奨事項を取得し、Kiro に変更（インスタンスのサイズ変更、ライフサイクルポリシーの追加、アイドルリソースの削除）をリポジトリへ直接実装させ、レビュー用にプルリクエストを作成させます。 コード全体のリソースに一括タグ付与： ファイルを手動で編集する代わりに、コードベース内のすべてのリソースに一貫したコスト配分タグ付け戦略（コストセンター、プロジェクト、環境）を 1 回で適用できます。 出力がコード、設定、またはデプロイメントアーティファクトであるあらゆる技術的な FinOps タスクの自動化： タグ付けを強制するポリシー、コストガードレールとなるSCP、予算アラーム、または未使用リソース用のスケジュール実行されるクリーンアップスクリプトを作成します。 1 つのプロジェクトについて複数アカウントにまたがるコストをクエリ： Cost Explorer の請求ビューを使用して、支出を 1 つのプロジェクトに絞り込み、Kiro に数値の取得と要約、およびその数値に基づく対応を依頼します。 Amazon Q Amazon Q （in the AWS Console）とは：AWS マネジメントコンソールに直接組み込まれた、生成 AI によるコスト管理アシスタントです。AWS への支出について自然な言葉で質問すると、分析、可視化、実行可能な推奨事項が得られるため、複数のツールを行き来する時間を削減できます。主な利点は、Amazon Q がお客様のアカウント内で動作するため、ワークロードのすべての要素とそれらの相互作用を把握できることです。 FinOps で Amazon Q をいつ使うのか コンソール内での根本原因のコスト調査： 「先週、コストが増えたのはなぜですか？」と聞くと、Q が複数のソースから自律的にデータを収集し、仮説を検証し、変化の背後にある特定のサービス、アカウント、および使用量の要因を特定します。 節約機会の発見： Cost Optimization Hub と Compute Optimizer から、サイズ適正化、アイドルリソース、コミットメントベースの割引に関する推奨事項を 1 つの会話で明らかにします（例：「コスト最適化の機会として上位のものは何ですか？」）。 オンデマンドのコスト見積もり： 「ダブリンの  Amazon Simple Storage Service  (S3) に 1 PB を保管するにはどれくらいの費用がかかりますか？」といった料金と予測に関する質問に答えます。コンソールから離れずに構築前のコストモデリングを行えるため、この機能が役立ちます。 セルフサービスのコスト可視化： Amazon Q が Cost Explorer のフィルターを自動更新できるようになったため、チャートやテーブルなどを動的に作成することも、Cost Explorer 経由で作成することもできます。 AWS DevOps Agent AWS DevOps Agent とは：いつでも対応できるチームメイトとして機能するフロンティア AI エージェントです。本番環境のインシデントを自律的に調査し、オブザーバビリティスタック、デプロイパイプライン、コードリポジトリにまたがるシグナルを相互に関連付けることで根本原因を特定し、将来の問題を防ぐための改善を積極的に推奨します。現在は GA で、2 か月の無料トライアルがあります。DevOps Agent は FinOps にとどまりませんが、スキルとデータへのアクセスを提供することで、コストを意識した状態を保たせることができます。動画「 AWS DevOps Agent for FinOps 」をご確認ください。 FinOps で AWS DevOps Agent をいつ使うのか 自動インシデント調査： CloudWatch のアラームが発生すると、エージェントはすぐに調査を開始できます。そのため手動でのトリアージが不要になり、エージェントがログ、メトリクス、トレース、最近のデプロイを相互に関連付けて、根本原因を数時間ではなく数分で特定します。インフラストラクチャにサイズ適正化の変更を加えている場合は、DevOps Agent に使用状況への影響を監視してもらうことで、問題が起きていないかを確認できます。 ダウンタイムのコスト削減： インシデントを 3〜5 倍速く 解決することで、停止による収益や生産性への影響を軽減できます。これは多くの場合、組織内で追跡されていない最大のクラウドコストです。 インフラストラクチャの推奨事項についてコストを念頭に置く： エージェントは過去のインシデントを毎週分析して改善を提案します。DevOps Agent に、コストも考慮すべき要素であると伝えておけば、最適化された改善案を探し、事後対応型から計画的な最適化作業へと支出をシフトするのに役立ちます。 まとめ：FinOps ペルソナに合った適切なツールを選ぶ それぞれのツールが何をするのかを知ることと、特定の場面でどのツールを使うべきかを知ることは別のことです。下のグリッドは、6 つの FinOps ペルソナ （行）と 5 つの AI ツール（列）をマッピングしています。各セルには、適切なデータ接続を前提として、そのツールで使用するサンプルプロンプトが各ペルソナの視点から書かれています。クイックリファレンスガイドとして活用してください。自分の役割を見つけ、行を横に見ていき、各ツールが日常業務にどのように役立つかを確認しましょう。一部のツールは機能が重複していることに気づくでしょう。どのツールが最適かは、どこで作業しているか、何を作ろうとしているのか、そしてどれだけ深く掘り下げる必要があるのかによって決まります。 ペルソナ別の FinOps AI ツールのプロンプト ペルソナ AWS FinOps Agent Amazon Quick Kiro Amazon Q AWS DevOps Agent FinOps Practitioner 「CRON 自動化を使用して、いずれかのチームの 1 日の支出が 30 日間の移動平均を 25% 超えたら通知してください。根本原因分析を行い、オーナーチーム向けの Jira チケットを作成してください。」Jira インテグレーションが必要です 「フレームワークの進捗状況を追跡するために、タグ付けコンプライアンス、コミットメントカバレッジ率、およびチームレベルの導入指標を含む FinOps 成熟度の概要を作成してください。」 「毎週すべてのアカウントをスキャンし、チームの FinOps 成熟度を評価し、改善アクションプランを生成するタグ付けコンプライアンスの自動化を構築してください。」 「コミットメントカバレッジが最も低く、無駄が最も多いチームはどれですか？今四半期の FinOps 支援の重点分野を優先的に決めるのを手伝ってください。」 「チームが FinOps のベストプラクティスに従わなかったことが原因で発生した前四半期のインシデントを分析してください。FinOps 文化への投資のビジネスケースを構築するのを手伝ってください。」 Engineering 「過去 3 か月で最大のコスト要因は何でしたか？アーキテクチャを大きく変更せずにコストを節約するにはどうすればいいですか？」 「リソーストラッカーを構築してください。サービス別のデプロイあたりのコスト、環境別のアイドルリソースインベントリ、オートスケーリングの効率指標を含めてください。」 「コスト最適化の機会について、この Terraform モジュールをスキャンしてください。サイズが大きすぎるインスタンス、オートスケーリングが設定されていないもの、コスト配分タグが付いていないリソースにフラグを付けてください。タグ付けを自動修正し、コスト削減のためのアーキテクチャ変更を提案してください。」 「us-east-1 のどの Amazon EC2 インスタンスが 10% の CPU 使用率を下回っていますか？サイズ適正化による推定月間節約額はどれくらいですか？」 「オートスケーリンググループは、オフピーク時にオーバープロビジョニングになっています。CloudWatch のメトリクスを分析し、SLO の目標を維持しながら、スケジュールベースまたは予測に基づくスケーリングポリシーを推奨してください。」 Finance 「標準テンプレートを使用して、CFO 向けの PowerPoint ファイナンスレポートを生成してください。Slack 経由で毎月第 1 月曜日の午前 8 時に配信をスケジュールしてください。」Slackインテグレーションが必要です 「ファイナンスレポートを設計してください：事業部別の毎月の実績対予算、予測精度の追跡、チャージバック／ショーバックビュー、請求書の照合状況。」 「毎月の CUR／FOCUS ファイルに基づいて、コストセンター、環境、ビジネスユニットごとにグループ化されたコスト配分レポートを生成してください。」 「第 1 四半期と第 2 四半期のサービス別の前月比コスト差異を、連結アカウント別に表示してください。20% を超える差異を強調表示し、承認された予算基準を超える差異があればフラグを付けてください。」 「インフラ支出をサービスの信頼性指標と関連付けてください。投資不足による財務リスクを定量化してもらえれば、インシデント関連の費用に備えて正確な予算準備金を積むことができます。」 Product 「今月、ML 推論コストが 40% 増加した理由は何ですか？支出が当社の戦略的投資の優先事項と一致しているかどうかを判断できるように、製品機能とユーザーセグメントごとに分類してください。」 「アクティブユーザー 1 人あたりのコストの傾向を、6 か月にわたって製品ラインごとにビジュアライゼーションで示してください。ユーザー 1 人あたりの収益と重ね合わせ、ユニットエコノミクスの観点でどの製品が改善または悪化しているかを示してください。投資の優先順位付けに役立てます。」 「新機能リリースのコストモデルを作成してください。1 万人、5 万人、10 万人のユーザー規模でのインフラストラクチャコストを見積もり、各規模での ROI を示すビジネスケース文書を生成してください。」 「過去 90 日間で product:ProdA とタグ付けされたリソースの総費用はいくらですか？ユーザーあたりのコストを計算してください。当社の価格モデルがビジネスケースを裏付けていることを検証できます。」 「ProdA のコストパフォーマンス比を評価してください。コンピューティングに 20% 多く投資した場合、信頼性の向上はどのくらい見込まれますか？」 Procurement 「月額 5,000 ドル以上の節約額で絞り込んだ最適化の推奨事項を見せてください。次のベンダー契約交渉に使用できる調達概要を作成してください。」 「ベンダーコミットメントのポートフォリオダッシュボードを作成してください。すべてのテクノロジーカテゴリにわたって追跡できるようにしてください。」 「MCP で現在の Savings Plans と RI ポートフォリオを問い合わせてください。90 日後に期限が切れる契約を特定し、更新シナリオをモデル化し、レバレッジポイントを含む交渉概要を作成してください」AWS Billing and Cost Management MCP サーバーインテグレーションが必要です 「現在のコミット済み支出レートをオンデマンド料金と比較してください。ベンダー交渉に役立つ情報として、当社が過剰にコミットしている箇所とカバレッジにギャップがある箇所を特定してください。」 「特定されたリソースに基づいてインスタンスの一覧を作成してください。Graviton または Spot インスタンスの恩恵を受けるインスタンスファミリーとリージョンはどれですか？」 Leadership 「毎日午前 8 時に Slack のメッセージを送り、昨日の支出と戦略的予算、そして経営陣の注意が必要な異常を含めてください」 「すべての BU のクラウド ROI、コスト効率比、単価の傾向を示すエグゼクティブスコアカードを作成してください」 「自動化された経営層向けアラートシステムを構築してください。予算の 80% に達したときにマネージャーに通知を送り、どの取り組みが支出に影響を与えているかを伝えてください。」 「戦略的な概要を教えてください。12 か月間の AWS 総支出の傾向、次の四半期の予測、成長を牽引する上位 3 つのサービス、そしてクラウドへの投資と収益の伸びの相関関係です。」 「戦略的リスクレポートを生成してください。当社のインフラ投資がビジネスの優先事項と一致していない箇所に焦点を当ててください。」 結論 最も成果を上げている FinOps プラクティショナーは、AI ツールの機能を成果に合わせて選び、ビジネス価値が確実に提供されるようにしています。今いるところから始めましょう。コストのスパイクを手動で調査するのに何時間も費やしている場合は、AWS FinOps Agent を試してみてください。ステークホルダーからの「X はいくらかかりますか？」という場当たり的な質問に追われているなら、コンソールの Amazon Q を案内するか、Amazon Quick を設定してください。開発者がコストガードレールなしでリソースをデプロイしている場合は、Kiro から始めてもらいましょう。そして、既製の選択肢のどれも自社独自のワークフローに合わない場合、それがまさに Amazon Bedrock の出番です。 FinOps を取り巻く AI の状況は急速に進化しています。早い段階で実験に取り組むプラクティショナーこそが、人員を増やさずに影響力を広げられるようになります。これらのツールはすべて価格体系が異なるため、使い始める前に必ず確認してください。完璧なタイミングを待たないでください。小さく始めて、早く学び、繰り返してください。まずは、このブログの各所でリンクしているツールを見てみてください。また、より実践的なコスト最適化のガイダンスについては、「The Keys to AWS Optimization」を参照してください。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Steph Gooch Steph は Sr. Optimization Solutions Architect Advocate です。現在および将来の AWS 支出を最適化する方法についてお客様を導く、当該分野の専門家です。お客様が請求データや使用状況データを整理して解釈し、そのデータから実用的なインサイトを特定し、コストを企業文化に組み込むための持続可能な戦略を策定できるよう支援しています。以前のキャリアでは、ビッグ 4 の 1 社で FinOps チームを率いていました。 Jenny Shen Jenny は、AWS で通信・メディア・エンターテインメント分野を担当するソリューションアーキテクトです。お客様が本番環境に対応したシステムを構築できるよう支援し、チームによるクラウドワークロードの運用を簡素化する方法を見つけることに情熱を注いでいます。以前のキャリアでは、ビッグ 4 の 1 社の FinOps プラクティスで働いていました。

「技術ブログを書け、PVを伸ばせ」と言われたあなたへ ども！1年間AIと一緒に活動してきた龍ちゃんです。 「技術ブログを書け、PVを伸ばせ」 会社からそう言われているエンジニア、いませんか？文章書くのは苦痛で、タイトルの付け方もメタディスクリプションの書き方もマーケの話も全然わからない。 先に、この記事で渡したいものだけ。個別のTipsでも「AIがすごい」って話でもなくて、 文章が苦手なエンジニアでも、ネタ切れせずにブログを続けられる仕組み です。検証から公開までの全工程を、ひとつのパイプラインとして見せます。タイトルもマーケも苦手なまま始められますよ。 これだけ「苦手」と言っておきながら、「この1年でAI活用が一番進んだ業務は？」と聞かれたら、答えはブログなんですよね。書き方も、昔は「やったことを順に書く実装ログ」だったのが、今は「読者のつまずきを起点に、検証結果を証拠として置く」形に変わりました。同じ人間が書いてるのに、です。AI活用の集大成として、今回まとめることにしました。 ちょうど1年前にも 「これが僕の執筆環境です」という記事 を1本書いてるんですけど、そこから工程ごとに道具を足し続けた結果が、今回話すパイプラインです。 大事にしている考え方は2つあります。 検証してから書く 。ネタを探してから書くのではなく、検証した結果が記事になる。だからネタに詰まらない 道具を使い捨てず仕組みに沈める 。便利な使い方をその場限りにせず、次も使えるように残す 順番に説明していきますね。 検証・調査からはじまる、Claude Codeで組んだパイプラインの全体像 まずざっくり全体を見てもらいます。 全工程にAIが居ます。調査もアウトライン作りも公開前のチェックも図もサムネも、どこを切ってもAIが何かやってます。ただ、 執筆だけ役割が反転します 。他の工程はAI主導で人間が確認するイメージなんですが、執筆だけは人間主導でAIが補助に回る。なぜそうなるのか、は後半で回収しますね。 なお、この記事に出てくる research-searcher みたいな名前は、それぞれ役割を持たせたAIに付けた呼び名です（僕は Claude Code の skill とサブエージェントで組んでます）。名前は覚えなくて大丈夫なので、「何をする担当か」だけ追ってもらえればOKです。あと、これ全部を自作しないと始まらない話でもないです。普段使ってるAIに同じ役割を振るだけでも回ります。 もう1つ前置きを。7工程のうち5つ（アウトライン / 執筆 / 公開前チェック / 図・サムネ / タイトル・SEO）は、それぞれ単独の記事で深掘りしてあります。なのでこの記事では、その5工程は「何をする工程で、なぜその形にしたか」と、さらっとしたコツだけを置いておきます。気になる方はぜひ個別記事も読んでみてください。 工程ごとに、上流から歩いてみる 工程は7つ。順に見ていくと、AIへの任せ方が工程ごとに違うのが見えてくると思います。 検証してから書く。だからネタ切れしない ブログの起点は「ネタ出し」じゃないんですよね。「検証・調査」なんです。 「よくネタが尽きないね？」って聞かれることがあるんですが、答えはシンプルで、自分の中に1つルールがあって。 検証した内容を基本的にブログ化する ってことを守ってます。 何か気になる技術があって、実際に手を動かして、「あ、こういう結果になった。これはブログにする価値があるな」と判断してから書く。逆に、ネタだけ考えて実装なしで「仮想のブログ」を書こうと思えば書けるんですけど、個人的にそれをやったら終わりだなと思ってて。技術ブログとして 動くものを提供できる 状態を維持することは、最低限守ることにしてます。 ここで効いてくるのが、 検証する場所と記事を書く場所が同じリポジトリにある 、という構成です。気になったら即AIに調べさせて 「放置案件」を作らない 。 調査の品質を /research で揃えて から書き始めると、書いてる途中で主張がブレなくなる。そうやって手を動かした結果は、 docs/research や docs/experiment にメモとして溜まっていきます。検証と執筆が地続きだから、検証した結果がそのまま記事の素材になるんですよね。 で、ネタの話なんですけど。溜まった検証メモを横断検索すると、「これ1記事になるな」という種が自然と立つんですよ。ここは Skill×サブエージェントで調査を速く回す構成 にした専用のエージェント（調査メモを横断検索する research-searcher や、過去のブログを照合する blog-searcher ）に探させてます。だから僕の中に「ネタを探すフェーズ」って実はないんですよ。むしろ逆で、 検証したことがネタになる んだから、検証していないことはそもそも記事にならない。ネタは探すものじゃなくて、検証から生まれるものなんです。そう捉えると、手を動かして検証を続けている限り、「ネタ切れ」という状態そのものが起きなくなるんですよね。「ネタを探す」は「自分の活動の振り返り」に近いかもしれません。 いきなり書かず、アウトラインで勝負を決める ネタが決まったら、次はアウトラインです。誰に・どの検索で届く記事か・どの角度で書くかを、本文を書く前に決めきる工程ですね。少しマーケティング的知識を入れておきます。 書く前に決めきる理由は単純で、「誰に届ける記事か」の設計は執筆より上流でしか機能しないからです。書き始めてから「あ、読者像ずれてたな」となると直すのが本当に大変なので。あと、ここで「うーん、わざわざ書くほどでもないな」となった記事を、1文字も書かずに畳めるのも大きいです。 この工程のコツを1つ。 アウトラインが「方法をN個並べる」形になったら、1記事に詰めるのをやめて分けたほうがいい です。見るのは、並べた方法どうしで読者に要求する思考が同じかどうか。「読者のペインが同じ」はまとめる理由になりません。実はこのシリーズがまさにそれで、最初は1本に詰めるつもりだったのが、工程ごとに読者へ要求する思考が違いすぎて5本に割れました。あと量の目安として、アウトラインは50〜60行で止めてます。超えたら本文を先食いしてるサインで、執筆が「アウトラインの清書」になるんですよね。 アウトラインを先に作ることで、前提知識などが見えてくることがあります。そういった「自分は知っている」けど、みたいな情報に気づくとまたそれも新規のブログネタになるという感じですね。あとは分量が増えたら分割みたいなこともとれるので、時間がなくてもサクッとアウトラインだけ作るのはおすすめです。AIと話して作ればそんなに時間もかからないですしねw そのアウトラインをAIにレビューさせる話（狙う角度を探す担当と、読者の代弁をする担当の2体）は、別記事に書きました。 2026-08-06 技術ブログの手戻りが消える、アウトラインのAIレビュー 執筆は、素材を渡して下書きを作り、最後は自分の目で通す 執筆は、ここまでで溜めた検証メモ・調査・過去記事を素材として渡して、文体を担当するAI（writing-stylist）に下書きを起こさせる工程です。音声入力でしゃべった内容を素材に混ぜることもあります。 ただ1個だけ、あえて仕組みに「落とさない」ところがあって。出てきた下書きを 自分の目で見て「これ、自分が書きそうか？」を判断して直す 。ここはAIに渡さず自分でやります。 正直、執筆の完全分離はできずにAIとけんかしている日々ですね。それでも執筆速度自体は上がっているので結構お勧めな手法です。 自分の文体をどこまで再現できて、どこから中身が捏造されるのか。その実物は別記事にあります。 2026-08-06 技術ブログで自分の文体をAIに再現させて時短を目指す 公開前は1体に全部見せず、観点で割る 下書きができたら、公開前に検査します。 ここで大事なのは、1体のAIにレビュー観点を盛り込みすぎないことです。それをやると観点が混ざって、「全体的によく整理されています」みたいな当たり障りない感想しか返ってこない。なので 観点ごとに別のAIに割って 、1体には1つだけ目的を持たせてます。いま割ってるのは、書いてはいけないことが混ざってないかのリスク検査、辛口の批評、論理の検算です。割ると、各担当が遠慮なく尖った指摘を返してくるんですよね。 ここで効いてるやり方が2つあって。 1つは、 表現の検査を別立てにする ことです。過剰な言い切り、前振りのない唐突な話題転換、「様々な」みたいなぼかし語といったやつですね。これは論理の破綻とは別の壊れ方なので、専用の担当に分けたほうが当たります。あわせて、約物（記号やカッコの揺れ）はAIに判断させず、スクリプトで機械的に正規化してます。揺れてるかどうかは読まなくても分かるので、ここにAIを使うのはもったいないんですよね。 もう1つは、 内部リンクをAIに探させる ことです。公開済みの記事を全部リポジトリに取り込んであるので、「この段落から張れる過去記事ある？」と聞けるんです。自分の記憶で思い出せる過去記事なんて直近の数本だけなので、ここはAIに探させた方が確実です。これは後で出てくる「1リポジトリに集約する」構成の副産物ですね。 検査の中身と、どこまで無人化してどこから人間が裁くのかは、別記事で書きました。 2026-08-06 技術ブログの公開前チェックをAIに任せる：機械が弾き、人が裁く 図とサムネはAIに作らせて、いい出来は貯めて育てる 記事が一通りできたら、図とサムネを付けます。 ここもAIに作らせてます。図は説明したい構造をそのまま渡してHTML＋Tailwindで組んでもらい、それをPNGに変換します。サムネは記事のタイトルと内容を渡して生成する感じですね。文章だけで説明していたところに図が1枚入ると、理解のしやすさが結構変わるんですよね。 最初から一発でいい感じに出てくるわけではないので、出来を見て「もうちょっと詰めて」と作り直すループを回します。そして、いい図ができたらそれを references に保存しておく。次に作図させるとき、それが“お手本”として効いてくるんですよね。この記事に載っている図も、全部この流れで作りました。 サムネイルに関しては、HTMLのコードをパターンとして保存しておくことで再利用ができるようになっています。HTML→PNGの撮影もPlaywrightを使用するとAIが勝手に判断してくれて撮影まで行ってくれるので超便利ですね。 なお、図を「作る」ことより残ってた判断は「どこに置くか」なんですが、そっちの話は1本に切り出しました。 2026-08-06 ブログの図は「どこに入れるか」をAIに決めさせる 作り方を具体的に知りたい人はこちら。 Mermaid図をAIで自動生成する — フロー図やシーケンス図を、Figmaで2時間かけてたのが5分に。最初に試すならここから 図解をAIに丸投げして育てる — 気に入った図をreferenceに貯めるだけで、AIの作図が勝手に上手くなっていく仕組みの話 タイトルとSEOは、マーケティングを知らないままAIで補える 正直、文章を作るよりも苦手だった領域です。タイトルの付け方、メタディスクリプション、競合調査。マーケッターの方に聞いても何から手を付けていいか全然分からなくて、最初にAIに任せ始めたのもここからでした。 やってることは2段階で、上位記事のタイトルの付け方を調べさせて相場を掴んでから、自分の記事のタイトルとメタの案を出させる。採るか直すかは自分で決めます。ここがAIに任せやすいのは、 正しさの基準が自分の外にあるから なんですよね。上位に並んでる記事の付け方が相場で、公開後のPVが答え合わせになる。SEOの知識が自分になくても、相場に照らせば案の良し悪しは判断できるわけです。 1つだけ書いておくと、 タイトルを詰めるついでに、各章の見出しも一緒に見直します 。見出しは執筆しながら立てるんですが、書き終わってから読むと、看板に内輪の用語（エラーの内部名とか実装用語）が乗ってることがあるんですよ。それが出たら文言をいじって済ませず、その章が書き手目線になってるサインとして中身の順番から疑います。看板は「困ってる人が打つ言葉」で書きたいので。 正直に言うと、この工程はまだ仕組み化の途上です。「仕組み完成してます！」と書きたいところですが、そうじゃないので正直に書いておきます。 2026-08-06 技術ブログのタイトルとSEOは、書いた後にAIで詰める 公開したら記録する。書いて終わりにしない 公開して終わり、にはしてないんですよ。 ここで効いてくるのが、また「1リポジトリに集約してある」という構成です。公開した記事も、そのPVデータも、同じリポジトリに置いてある。すると PV分析をこのリポジトリの中で回せる んですよね。このブログはどういう読者層に届いて、なぜ伸びたのか。それを分析して、次の記事のアウトライン（企画）に戻す。 ポイントは「作業ログを残す」というより、 後から参照できる資産として記事と分析結果が同じ場所にある ことです。記事の中身も、PV分析の結果も、ひとつながりで手元に残る。 実際これが効いたことがあって。リポジトリの中でPVを分析したら、生成AI系の記事が圧倒的に読まれていて（うちのブログの場合、PVの8割以上がそこ）、その中でも伸びてるのはツール名を題に置いた実用ノウハウ系で、しかも新記事を出さない月は数字が落ちる、というのが見えたんですよ。結論はシンプルで「 Claude Code 系に絞って、新規記事をとにかく出し続けろ 」。で、実際にそのテーマでシリーズを書き始めました。分析と記事と過去ログが同じリポジトリにあるから、「数字 → 次に何を書くか」の判断をそのまま回せるんですよね。 調査メモも記事の素材も過去ログもPVデータも同じ場所にあると、「次に何を書くか」を決めるのに別の場所を探しに行かなくて済むんですよね。正直やってみないと分からないんですが、続けてみると「あ、これか」ってなると思います。 記録と集約は、それぞれ単独記事にしてます。 git logを作業ログにする話 — コミットをAIに書かせるだけで、git logがそのまま作業履歴に。中断からの復帰や週次の振り返りがラクになる 全業務を1リポジトリに集約した話 — 開発も調査もブログも1つのリポジトリへ。やった仕事が消えず「資産」として積み上がる作業基盤の作り方 全工程に共通して効いてる考え方 工程を全部並べてみると、根っこに通ってるものが見えてきます。冒頭で2つ挙げましたが、こうして並べるともう1つ足したくなるので、3つにして書いておきます。 ① 検証が先、ネタは後 ネタを探すのではなく、検証する。検証したことがネタになるんだから、検証していないことは記事にもならない。記事は検証の副産物として立ち上がるもので、この順番にしておくと「ネタ切れ」という発想自体がなくなるんですよね。 ② 便利技は使い捨てず仕組みに沈める 「これ便利だな」で終わらせない。一番手軽なのは、良い結果が出たら reference に保存して次のAIへの参考資料にすること（さっきの図・サムネが育つのがこれ）。もう一歩進めると、繰り返す作業はスキルやエージェントの形にして残す。どちらも「その場限りにしない」という同じ原則で、保存はその入口です。次に使うとき1から作り直さなくていいので、この積み上げがじわじわ効いてきます。 ③ 1体に欲張らず、観点で割る 公開前チェックのところで出てきましたが、1体のAIに全部やらせると観点が混ざります。用途ごとに割った方が、各エージェントが遠慮なく動くんですよね。これはレビューに限らず、他の工程でも同じ考え方です。 AI全部入りでも、最後に残るのは「これ自分が書きそう？」の判断 自分らしさとAIっぽさのせめぎ合い。その摩擦の中で、自分の言葉が研がれていく。 ここまで見てきた通り、検証から公開まで全工程にAIが居ます。執筆にもAIは居ます。文体エージェント（writing-stylist）が下書きを作るし、音声入力で口述することもある。 でも、執筆だけ役割が逆なんですよね。 他の工程はAIが主導して人間が確認する形ですが、執筆は人間が主導してAIが補助に回る。なんでそうなるか。 理由は、AIの出力が「合ってるか」を測る基準が、工程ごとに違うからなんですよね。もちろん他の工程も、最後は人間が見ます。でも図やSEOや調査は、合ってるか外してるかの基準が外側にある。図がちゃんと描けてるか、検索意図に合うタイトルか、事実が正しいか。だから人間は「確認役」で済む。ところが文章の「自分らしさ」だけは、基準が自分の中にしかなくて、誰かに「合ってます」と言ってもらえない。だから執筆だけ、確認じゃなく「主導」に回るんです。 AIが出してきた文章を読むじゃないですか。読んでいると、「これはちょっと違う」「ここは自分ならこう言わないな」って思う部分が出てくるんですよ。そこを直す。その修正の過程で自分らしさが入ってくるんですよね。音声入力でしゃべった言葉も同じで、そのまま入れるんじゃなくて「これは自分が言いそうか？」を確かめながら使う形ですね。 残るのは「文章をうまく書く力」じゃないんですよね。「 これ、自分が書きそうか？ 」を判断する力なんです。 まぁ正直、この作業をなくしてしまえば今の3倍ぐらいの量のブログを出せますね。ただ、それはただの量産作業な気がしてしまいます。なんとなく愛着も湧かないですよね。文体と自己が乖離しちゃうというか。割と大事にしている考え方です。 これ、「技術ブログを書け」と言われてるエンジニアへのアンサーでもあって。2つ理由があります。 ひとつは、だから量産する意味がないということです。自分らしさをメッセージとして注入していく作業なので、機械的に数を増やすのとは違うんですよね。感覚としては「自分らしさとAIっぽさのバトル」みたいな感じですw ちゃんとそれなりに疲弊します。 もうひとつは、実装した内容は、実装した自分にしか正しく判断できないということです。検証して動かした結果について「これは本当にこうだったか？」を確かめられるのは、手を動かした本人だけです。だから最終チェックは絶対に人間が要る。 ここが面白いなと思ってて。「いきなり自分らしく書け」って言われても、何が自分らしいのかって分からないじゃないですか。でも「AIが出してきた文章を見て、違うと感じる所を直す」なら、誰でもできるんですよ。生成より添削の方が、自分を出しやすい。文章を書くのが苦痛な自分でもこのパイプラインが回ってる理由は、ここだと思ってます。 何から始めるか、そして正直な限界 まず何から始めるか 「で、何から始めればいい？」と思った方へ。 おすすめは、 苦手な1工程からAIに任せてみる ことです。順番はこんな感じ。 苦手な工程を1つ選ぶ （僕はタイトルとメタディスクリプションでした）。使うAIは普段のもので大丈夫です。ChatGPT でも Gemini でも、Claude Code でも 過去記事があれば、何本かAIに読ませて文体や思想を抽出してもらう （まだ1本も無ければ、ここは飛ばしてOK） AIが出した案を「これ自分が書きそう？」で直す 。気に入らない所を直すだけでOK（生成より添削の方がラク） これだけで1工程は回り始めます。いきなりパイプライン全部を組もうとしなくて大丈夫。苦手なところを1個ずつ潰していくと、じわじわ繋がってきます。 もっと手っ取り早く全体像を相談したいなら、この記事ごと自分のAIに読ませて「マネできそうな所ある？」と聞くのもアリです。状況に合いそうな工程を拾ってくれます。 正直な限界 誇張したくないので書いておきます。 まず、 ネタや「気になる！」は人間発信 です。そこにモチベがないと、そもそも書かない。仕組みは「書こうとした人の作業を楽にする」ものなので、動機まで代替はできないですw あと、 最初から完成形は組めない です。続けてみて初めて「ここ変えよう・ああしよう」が出てくる。この記事で紹介した形も、1年かけて少しずつ固まってきたものです。最初から全部揃えようとしなくていいです。 文章を書く苦痛がゼロになるわけでもないです。相変わらず書くのしんどいですよw マーケ周りの分析もまだ仕組み化の途上で、手動でやってる部分があります。 まとめ：個人で完結する領域だからこそ、AIを試せた この1年で一番腑に落ちたことがあって。同じAI活用でも、本職のコードを書く仕事とブログでは勝手が全然違うということです。 本職のエンジニアの仕事でエージェントを使うとなると、結構ハードルがあるんですよ。後のメンテナンスとか、決定事項を流動的に把握しておかないといけなくて、AIに自由にやらせるというより、ガチガチに縛って使うことになる。 でもブログは違うんですよね。僕個人で完結するコンテンツなので、僕がどう思うかだけで決まる。だから 自分が使いやすいように、好きなだけ環境を整えられる 。 そして、この「自分が使いやすい環境を整える」行為そのものが、AI活用を学ぶ一番の場になったんです。skill の作り方、agent の設計、観点の分け方、みんなここで学びました。本職のコードを書く現場では踏み込みづらかった領域に、ブログという個人完結の場だからこそ踏み込めた。それが一番の収穫だったと思ってます。 パイプラインは人によって違っていいんですよ。「自分はこの工程が苦手」「ここは手放したくない」は人それぞれです。残すべき人間の領分を自分なりに見極めていく、その過程がたぶん大事で。 文章を書くのは相変わらず好きじゃないんですけど、「AI活用が一番できてる業務は何か」と聞かれたらブログだって答えると思います。それがこの1年の一番の発見でした。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeと書く技術ブログ：ネタ切れしない仕組みの作り方 first appeared on SIOS Tech Lab .