Blog

AIエージェントを業務に根づかせるための実践知と運用ノート

AIエージェントで仕事はどう変わるか

15
チャット活用から実行主体への変化 AIは相談相手から実行主体へ変わった
チャット活用から実行主体への変化 エージェントが仕事を引き受ける時代に企業が最初に見るべきこと
チャット活用から実行主体への変化 なぜAI活用は個人の時短だけで終わらなくなったのか
個人の爆速開発からチームの運用へ AI開発が属人芸で止まる会社に足りないもの
個人の爆速開発からチームの運用へ Claude Codeで速く作れる会社と運用できる会社の違い
個人の爆速開発からチームの運用へ 一人の成功体験をチームの標準手順に変える方法
コード生成から業務遂行への拡張 AIコーディングの次に来る業務遂行エージェント
コード生成から業務遂行への拡張 コードを書くAIから仕事を進めるAIへ
コード生成から業務遂行への拡張 営業リサーチからCRM更新までAIに任せる時に必要な設計
人間が設計しAIが実行する仕事の形 AI時代に人間の仕事は仕様と判断に移る
人間が設計しAIが実行する仕事の形 マネージャーこそAIエージェントを使うべき理由
人間が設計しAIが実行する仕事の形 よい成果物を定義できる人がAIを使いこなす
ツール導入ではなく業務基盤が必要になる理由 AI活用をイベントで終わらせないための基盤設計
ツール導入ではなく業務基盤が必要になる理由 Claude Codeを入れても業務基盤がなければ成果は残らない
ツール導入ではなく業務基盤が必要になる理由 生成AI研修の次に整えるべき業務基盤

人間が担う判断と責任

18
何を任せて何を任せないか AIに任せる仕事と人間が残す仕事の分け方
何を任せて何を任せないか 自律実行を始める前に決める任せる範囲
何を任せて何を任せないか 人間承認を減らす前に考えるべきこと
よい成果物を定義する力 AI時代のPMに必要な成果物定義力
よい成果物を定義する力 プロンプトより先に完了条件を書く
よい成果物を定義する力 レビューしやすいAI成果物の作り方
仕様を切る人の役割 AIに実装させる前に仕様を切る方法
仕様を切る人の役割 Claude Codeで成功するマネージャーがやっていること
仕様を切る人の役割 要件定義が弱いチームほどAIで迷走する理由
レビュー責任の置き方 AIが作ったPRを人間が見る時の基準
レビュー責任の置き方 AI生成コードのレビュー責任は誰が持つべきか
レビュー責任の置き方 受託開発でAIを使う時のレビュー設計
承認を入れる場所 AIエージェントに人間承認を入れるべき場面
承認を入れる場所 自律実行を安全に広げるための承認設計
承認を入れる場所 承認フローがあるAI自動化とないAI自動化の違い
対外説明できるAI利用 AIを使った成果物の説明責任をどう持つか
対外説明できるAI利用 顧客に説明できるAI利用ルールの作り方
対外説明できるAI利用 受託開発会社がAI利用を隠さず説明する方法

AI開発運用の実践知

18
AIコーディングをチーム標準にする設計 AIコーディングを個人技からチーム標準に変える方法
AIコーディングをチーム標準にする設計 Claude CodeとCodexをチームで使う時に最初に決めること
AIコーディングをチーム標準にする設計 CursorやClaude Codeをツール比較で終わらせない導入設計
CLAUDE.mdとAGENTS.mdの運用 AIに毎回同じ説明をしないためのリポジトリ設計
CLAUDE.mdとAGENTS.mdの運用 CLAUDE.mdとAGENTS.mdは何を分担すべきか
CLAUDE.mdとAGENTS.mdの運用 チームで育てるAI作業指示書の作り方
PR分割とレビュー設計 AIに大きすぎるPRを作らせない方法
PR分割とレビュー設計 AI生成PRの品質を落とさないレビュー導線
PR分割とレビュー設計 レビューしやすいAI開発タスクの分け方
利用制限とコストを織り込む運用 AI開発のコストが読めないチームに必要な管理方法
利用制限とコストを織り込む運用 Claude Codeの利用制限を前提にしたチーム運用
利用制限とコストを織り込む運用 サブスクとAPIとOSSモデルをどう使い分けるか
開発ログと再実行性 AIが何をしたか後から追える開発ログの残し方
開発ログと再実行性 作業履歴を次のPRに活かすAI開発運用
開発ログと再実行性 失敗したAI作業を再実行できる状態にする
受託開発でAI利用を説明する方法 AIを使う受託開発の見積もりと責任範囲
受託開発でAI利用を説明する方法 顧客に安心してもらうAI開発運用の見せ方
受託開発でAI利用を説明する方法 受託開発会社がAI利用ポリシーを作る理由

顧客データと権限境界

18
AIに渡してよい情報の分け方 AIに渡してよい情報と渡してはいけない情報
AIに渡してよい情報の分け方 顧客データをAIに使わせる前に分類する
AIに渡してよい情報の分け方 社内情報と顧客情報を分けるAI利用ルール
顧客データを扱う時の前提条件 NDAがある案件でAIを使う時に確認すること
顧客データを扱う時の前提条件 顧客データをAIエージェントが扱う時の前提条件
顧客データを扱う時の前提条件 顧客文脈をAIに渡す時の安全な設計
本番環境に触らせる条件 AIエージェントに本番環境を触らせる条件
本番環境に触らせる条件 AIにデプロイさせる前に整える権限設計
本番環境に触らせる条件 ステージング自律と本番承認を分ける
SaaS連携時の認証と権限 AIにSaaSを操作させる時の認証設計
SaaS連携時の認証と権限 OAuthとAPIキーをAI運用でどう扱うか
SaaS連携時の認証と権限 社内SaaS連携で事故を起こさない権限分離
禁止操作と例外処理 AIエージェントの禁止操作リストを作る
禁止操作と例外処理 削除送信決済をAIに任せる前に決めること
禁止操作と例外処理 例外処理を決めないAI自動化はなぜ危ないか
監査証跡と説明責任 AI作業の監査証跡をどう残すか
監査証跡と説明責任 顧客に説明できるAI作業ログの作り方
監査証跡と説明責任 誰が何を承認したか残るAI運用

文脈資産とCompany Brain

18
Context Engineeringを業務に落とす AIが毎回同じ説明を求める問題をなくす
Context Engineeringを業務に落とす Context Engineeringを社内業務で使うとは何か
Context Engineeringを業務に落とす プロンプトではなく文脈を設計する
社内ナレッジをAIが使える形にする ドキュメントがあるのにAIが使えない理由
社内ナレッジをAIが使える形にする 会議録と仕様書をAIの判断材料に変える方法
社内ナレッジをAIが使える形にする 社内ナレッジをAIが読める形に整理する
MarkdownとGitで育てる知識基盤 MarkdownとGitでAIが使える社内知識を育てる
MarkdownとGitで育てる知識基盤 NotionだけでAIナレッジ基盤を作ると詰まる理由
MarkdownとGitで育てる知識基盤 変更履歴が残るCompany Brainの作り方
商談記録と顧客文脈を再利用する CRMに眠る顧客文脈をAIが使える形にする
商談記録と顧客文脈を再利用する 営業リサーチから提案書まで文脈をつなぐ方法
商談記録と顧客文脈を再利用する 商談記録を次の提案に使えるAI文脈にする
作業履歴を次の判断に残す AI作業ログをチームの学習資産にする
作業履歴を次の判断に残す 過去の判断を次のAI作業に引き継ぐ方法
作業履歴を次の判断に残す 失敗したAI作業から次の手順を更新する
Company Brainを小さく始める Company Brainは大規模導入ではなく小さく始める
Company Brainを小さく始める 会社の判断基準をAIが使える形にする
Company Brainを小さく始める 最初にAIへ渡すべき社内文脈とは

属人作業を能力部品に変える

18
Skillを業務能力として捉える Claude Skillsを社内業務に落とす時の考え方
Skillを業務能力として捉える Skillは機能ではなく業務能力である
Skillを業務能力として捉える 一度うまくいった作業を再現可能にする方法
Playbookで手順知を残す Playbookで属人作業をAIに渡す
Playbookで手順知を残す プロンプト集ではなくPlaybookが必要な理由
Playbookで手順知を残す 担当者しか知らない作業を手順知に変える
成功した作業を再利用可能にする AI活用を再現可能な業務能力にする
成功した作業を再利用可能にする 一回限りのAI活用を社内標準に変える
成功した作業を再利用可能にする 成功したAI作業をテンプレート化する方法
失敗から手順を更新する AIの失敗ログから手順を改善する
失敗から手順を更新する なぜAI活用の失敗は資産化すべきなのか
失敗から手順を更新する 失敗を次のプロンプトではなく次の手順に反映する
部門別テンプレートを作る 営業リサーチ用AIテンプレートの作り方
部門別テンプレートを作る 開発チーム向けAIレビューPlaybookの作り方
部門別テンプレートを作る 制作会社向けAI作業テンプレートの作り方
社内能力ライブラリを運用する AI能力ライブラリにオーナーを置く理由
社内能力ライブラリを運用する 使われないテンプレートを増やさない運用
社内能力ライブラリを運用する 社内Skillライブラリをどう育てるか

外部接続と実行環境

18
AIに外部業務を任せる接続設計 AIに外部SaaSを触らせる時の判断基準
AIに外部業務を任せる接続設計 MCPを学ぶ前に考えるべき外部接続の設計
AIに外部業務を任せる接続設計 ツール接続を増やす前に決める責任範囲
CLIとSDKで自動化できること CLI操作をAIに任せると何が変わるか
CLIとSDKで自動化できること SDK連携でAIエージェントの実行範囲を広げる
CLIとSDKで自動化できること 開発者向けAI自動化の接続パターン
ブラウザ操作で変わる業務 CDPやブラウザ操作をAI運用に使う時の注意
ブラウザ操作で変わる業務 ブラウザ操作エージェントが業務自動化を変える
ブラウザ操作で変わる業務 人間の画面作業をAIに渡す時の境界
ローカル環境をAIが扱う意味 クラウドに出せない情報をAIで扱う設計
ローカル環境をAIが扱う意味 ローカルファーストAI業務基盤の考え方
ローカル環境をAIが扱う意味 ローカルファイルをAIが扱えると何が変わるか
ワークフローとスケジュール実行 AIエージェントを定期実行する時の設計
ワークフローとスケジュール実行 人間が寝ている間にAIが進める業務と承認
ワークフローとスケジュール実行 日次リサーチをAIワークフローにする方法
外部接続を安全に増やす考え方 AIツール連携を安全に増やす順番
外部接続を安全に増やす考え方 外部接続が増えたAI運用に必要な監査
外部接続を安全に増やす考え方 接続できることと任せてよいことは違う

評価と運用ガバナンス

18
AIエージェント評価の基本 AIエージェントを評価するとは何を見ることか
AIエージェント評価の基本 業務成果で見るAIエージェント評価
AIエージェント評価の基本 出力品質だけではAI運用を評価できない
Evalsとテスト設計 AIが作ったものをテストする仕組み
Evalsとテスト設計 Evalsを業務ワークフローに入れる方法
Evalsとテスト設計 受託開発でAI成果物を検証する基準
レビュー基準を作る AIレビュー基準をチームで持つ
レビュー基準を作る 人間レビューとAIレビューをどう分担するか
レビュー基準を作る 品質基準がないAI活用はなぜ広がらないか
ログと監査証跡を残す AI作業ログを残す理由
ログと監査証跡を残す 監査証跡があるAI運用とないAI運用の違い
ログと監査証跡を残す 後から説明できるAIワークフローの作り方
失敗復旧と再実行を設計する AIエージェントが失敗した時に戻れる設計
失敗復旧と再実行を設計する 再実行できるAI作業とできないAI作業
失敗復旧と再実行を設計する 自律実行にロールバックを組み込む
安全な自律実行の条件 AIに任せるほど人間の設計が重要になる
安全な自律実行の条件 安全に自律実行させるための条件
安全な自律実行の条件 自律化の前に必要なガバナンス

業務別のAIワークフロー

21
開発チームのAI DevOps Claude Codeを使うチームの運用チェックリスト
開発チームのAI DevOps 開発チーム向けAI DevOpsの始め方
開発チームのAI DevOps 受託開発会社がAI DevOpsを導入する順番
営業リサーチOps AIで営業リサーチを毎日回す方法
営業リサーチOps リード獲得をAIワークフローにする
営業リサーチOps 商談前リサーチをAIに任せる時の品質基準
CRM更新Ops CRMが更新されない問題をAIで解く
CRM更新Ops 顧客文脈を営業チームで再利用する方法
CRM更新Ops 商談記録からCRMを自動更新する考え方
Web制作会社のAI制作Ops Web制作会社がAIを制作フローに入れる方法
Web制作会社のAI制作Ops デザイン提案からコーディングまでAIでつなぐ
Web制作会社のAI制作Ops 制作物の品質を落とさないAI制作Ops
コンテンツ制作Ops AI記事を量産ではなく知識資産にする方法
コンテンツ制作Ops 調査から記事化までAIで回すコンテンツ制作
コンテンツ制作Ops 動画とSNSと記事をつなぐAI制作ワークフロー
経営企画リサーチOps 意思決定に使えるAIリサーチの条件
経営企画リサーチOps 経営企画の調査業務をAIワークフローにする
経営企画リサーチOps 市場調査と競合調査を毎日更新する仕組み
研修後のAI定着Ops 研修で終わらせないAI定着の設計
研修後のAI定着Ops 生成AI研修のあとに必要な90日運用
研修後のAI定着Ops 部門別ワークフローを作るAI定着支援

ユーザー所有のAI業務基盤

18
自社の文脈を外に預けない設計 クラウドAI時代にlocal firstが必要になる理由
自社の文脈を外に預けない設計 ユーザー所有データでAI業務基盤を作る
自社の文脈を外に預けない設計 自社の文脈を外に預けないAI活用
Hermesで運用するAIワークスペース Discordから動くAI業務ワークスペース
Hermesで運用するAIワークスペース HermesでAI作業を常駐運用する意味
Hermesで運用するAIワークスペース 個人AIからチームAI運用へHermesで移行する
Chroでつなぐ実行環境 ChroがAIエージェントの実行環境になる理由
Chroでつなぐ実行環境 ブラウザとローカル環境をAIに橋渡しする
Chroでつなぐ実行環境 画面操作とコード実行をつなぐAI基盤
Amendで扱う顧客文脈 営業現場の文脈を失わないAI運用
Amendで扱う顧客文脈 顧客文脈をAIが使える形で扱うAmendの考え方
Amendで扱う顧客文脈 商談記録とCRMをAIワークフローでつなぐ
Adbrandで扱う制作ワークフロー ブランド文脈をAI制作に渡す方法
Adbrandで扱う制作ワークフロー 制作ワークフローをAIで運用するAdbrandの考え方
Adbrandで扱う制作ワークフロー 制作物を一回限りで終わらせないAI運用
Agent Workspaceとして統合する未来 Skuncが目指すユーザー所有のAgent Workspace
Agent Workspaceとして統合する未来 バラバラのAI活用をAgent Workspaceに統合する
Agent Workspaceとして統合する未来 仕事の文脈と実行環境をつなぐAI業務基盤