はじめに

生成AIは確率的に返答を生成するため、同じ質問をしてもブレが出ます。何度も同じことを聞き直して、運よくいい答えが返ってきたら採用する——そんな「ガチャ」のような使い方をしていませんか？

本記事では、生成AIで狙った通りの成果物を出すための考え方と実践について取り上げます。対話型AIの仕組みから始め、AIエージェント、Agentic Codingなど、「どうすればAIの成果物を統制できるのか」を体系的に整理します。最後に、組織レベルでのAI活用としてAIプラットフォームとAIデータ基盤にも軽く触れます。

こんな方におすすめ

生成AIを使っているが、思い通りの結果が出ないと感じている方
コーディングエージェントに興味があるが、どういうものかさっぱりわからない方
Agentic Codingを自分の業務で応用できないか考えている非エンジニアの方

生成AIでフィードバックループを回す

テスト駆動開発の第一人者であるエンジニアの和田卓人さんの講演で、「労力は外注できるが、能力は外注できない」というものがありました。

生成AIはさまざまなことができ、実行を委ねることができます。しかし何をやらせるかを適切に設計しないと、見当違いの方向に延々と動き続けたり、本来やるべきでないことまで手を出したりといった事態になります。だからこそ、人間の側が十分な能力を身につけ、的確に統制する必要があります。

このとき重要になるのが、生成AIを「計画」「実行」「評価」というフィードバックループのすべてで活用するという考え方です。

計画 with AI：実行の前に目的と実行内容を整理し、効果的かつ効率的な実行を行えるようにする
実行 with AI：知識やスキルの不足を補完し、高速かつ高度な実行を行う
評価 with AI：実行内容の妥当性について詳細に評価し、計画の修正および知見の習得を行う

「実行」が高速化・高度化すると、それまでの自分の枠を超えて成果が出せるようになります。これはAI活用の革命的なところですが、派手に見えるため「実行」ばかりが注目されがちです。

しかし、「実行」に加えて「計画」と「評価」でAIを活用して学習を加速させることで、AIでできることの幅が広がり、精度が上がり、的確に統制できるようになっていきます。

現時点のAIは「強い人をより強くする」ツールです。それらしいアウトプットに満足せず、知的な基礎体力を積み上げ続けることが、差を広げていくことになります。

対話型AIの仕組みと、その拡張

ChatGPTやGeminiをはじめとする対話型AIは、生成AI活用の出発点です。その仕組みを理解することは、AIエージェントやAgentic Codingといった発展的な活用を押さえる土台になります。ここでは、対話型AIがどのように返答を生成しているのか、そしてその挙動を人間側からどのように調整できるのかを整理します。

LLMとは

前提として、LLM（Large Language Model、大規模言語モデル）とは、ある言葉のあとにどのような言葉がくるのが確率的に高いかという観点から言語を生成するものです。あくまで「確率的な挙動」がベースになっており、このときの確率が「どの範囲の確率を対象とするか」が重要な観点になります。

利用にあたっての注意点

具体的な説明に入る前に、1つ注意点をおさえておきます。生成AIサービスの利用時にその内容が学習に利用されるかどうかは、最初に確認すべき事項です。これによって入力が許容されるデータの範囲が変わってきます。

商用利用では、学習に利用されるサービスに機密情報を入れるのは厳禁
無料プランでもオプトアウトできることがあるので、利用開始時にまず調べる

また学習の有無に関わらず、リスクのある情報はなるべく入れないことが基本です。

個人情報
セキュリティリスクのある情報（APIキーなど）

学習に利用されないとしても、サービス提供者がその情報を閲覧できる可能性があります。

技術の進歩に対して、法的な位置づけの整理はまだ途上です。例えば以下の記事は参考になります。

いずれにせよ、データを扱う人は、そのデータを取り扱うことの責任を持つこと。これはAIに関わらず非常に大事なことであり、過失・故意を問わず、データを提供してくれた人に対する責任があります。

対話型AIの全体像

では、ここから具体的な説明に入っていきます。対話型AIの仕組みは以下の図で整理できます。

人間が工夫するか、サービス側が裏側で処理してくれているかという違いがあることもありますが、いずれにせよ大枠は以下の4つです。

①モデル開発：基盤モデルをどのように開発するか（どのモデルを利用するか）
②プロンプトエンジニアリング：どのような指示を出すか
③コンテキストエンジニアリング：どのような文脈情報を渡すか
④アクション：どのように拡張された行動をさせるか

この4つのうち、どれを調整すると成果物がどう変わるのかを意識することが重要です。次からは、このそれぞれについてポイントを整理していきます。

①モデル開発

学習の元データと学習方法によって基盤モデルが開発され、それに追加学習データを加えることで追加学習モデルが構築されます。

例えばサイバーエージェントは、DeepSeek R1という中国で開発されたオープンモデルに日本語データで追加学習を行い、日本語でも高精度な返答が行えるモデルを開発・公開しています。

ただし、モデルを個別に追加学習させる手間よりも、新たなモデルが公開されて性能が向上する速度のほうが速いことも多く、公開されたモデルをそのまま使うこともよくあります。実務的にも、運用コストの観点から「追加学習よりコンテキストエンジニアリング」が選ばれる傾向にある印象です。

そこで、軽い利用をしている限りでは工夫の余地はあまりなく、ポイントは以下の通りです。

トークン消費（＝コスト）を別にすれば、最新のモデルを利用する
思考が深く精度が高いが返答が遅いモデルと、精度は低いが返答が早いモデルを使い分ける（例：GeminiのFlashとPro）
テキスト生成に限定しなければ、動画や画像、音楽生成など、目的に応じたモデルがある

②プロンプトエンジニアリング

以前はプロンプトの書き方によって精度が劇的に変わったため、書き方の工夫が非常に重要でした。最近ではモデルの性能が向上したことで、小手先のテクニックの重要性は相対的に下がった印象です。返答が期待と違うときは追加で聞き直せばよいということでもあります。

とはいえ、プロンプトの書き方によって返答はだいぶ変わるので、少し工夫するだけでも十分に役立ちます。このとき、2つあるプロンプトの種類を上手く使い分けましょう。

ユーザープロンプト：プロンプトの表現・指示内容を調整することでLLMの返答を調整するもの
システムプロンプト：プロンプトを実行する際に必ず準拠するように依頼する指示

特に、対話型AIではシステムプロンプトとして好みの返答形式（簡潔に答える、言葉遣いをどうする、信頼度に応じた返答をさせる等）を指定するだけでも、かなり返答の質が変わってきます。

ポイントは以下の通りです。

何について聞きたいかを明確にする
返答に重要な補足情報を与える
どういう返答が欲しいかを指定する
つまり、「どの範囲における一般性の話なのか」を考える

③コンテキストエンジニアリング

LLMが標準で知っていることには限界があります。

モデルはその学習データの時点までの情報しか持っていない
学習データに含まれる、一般性の高い情報しか持っていない
このままでは、答えられないか、知ったふりをして嘘（＝ハルシネーション）を返す

これを補うために必要な背景情報（＝コンテキスト情報）をLLMに渡すのが、コンテキストエンジニアリングです。例えば、対話型AIで何度対話しても前の内容を踏まえて回答してくれるのは、実は裏側で過去の対話情報がコンテキストとして渡されているからです。

コンテキストによる補完が特に重要になるのは、扱う情報の「一般性」が低い場合や「鮮度」が必要な場合です。

	情報の鮮度：古	情報の鮮度：新
一般性：高	得意な領域	情報がないのに答えようとしがちな領域 →新鮮な情報を取得して補完すればよい
一般性：低	わかったようでわかっていない領域 →対応する文脈の情報を与えてあげればよい	そのままではどうしようもない領域 →新鮮な情報の補完＆文脈情報の提供が必要

なお、モデルの発展に伴いコンテキストウィンドウ（＝AIが一度に扱えるテキスト量）は広がってきています。しかし情報を大量に突っ込めばいいかというとそうでもなく、量が多すぎるとLLMが混乱して効果的に機能しなくなります。特に、入力の中間にある情報が抜け落ちる傾向にあることが知られています。

そこで、ポイントは以下の通りです。

LLMが知らないことを補完的に渡す
無駄な情報は省いて、必要最低限に絞る

④アクション

厳密な用語は別にして、質問に対してテキストで返答する以外の行動ができると理解すればよいです。例えば、ChatGPT、Gemini、Claudeで対話の内容に合わせて自動でWeb検索ができるようになっているのも、「実行できるアクションとしてWeb検索が登録されていて、状況に応じて自動でそれを利用している」という仕組みです。

ポイントは以下の通りです。

ライトな利用では「機能拡張や外部連携」と理解すればよい
Agentic Codingでは、MCP（Model Context Protocol）やSkillsとして実行できるアクションを拡張できる
- MCP：実行できるアクションを登録するための標準規格
- 例えばGitHubやGoogleとの連携など、外部ツールとの連携もアクションの拡張の一種

対話型の拡張としてのAIワークフロー

AIワークフローとは、インプット・処理・アウトプットを外部に連携させながら利用する形式です。ワークフローは決定論的に（＝必ず定義した通りに）動作するので、確率論的な動きをするLLMの挙動と組み合わせて利用されます。

というのも、確率論的に動くLLMにすべてを委ねるのは難易度が高いため、ワークフローで決定論的に処理できるところと、LLMに判断を委ねるところをグラデーションで使い分けることになります。

この考え方は、後述するAgentic Codingをするときも重要なもので、何は決定論的に進めて、何は確率論的に進めるのかの全体をデザインすることが期待通りの成果物を生み出すためのポイントです。

AIワークフローのサービスとしては、Dify、n8n、Google Workspace Studioなどが利用されています。

AIエージェント

対話型AIが「一問一答」に近い使い方だとすると、AIエージェントは「課題解決のプロセスごとAIに委ねる」使い方です。ここではその仕組みと特徴を整理します。

AIエージェントとは

AIエージェントとは、課題のタスクへの分解、分解したタスクの実行、実行内容を踏まえた完了判断など、課題の解決における「思考・判断」までAIが行うものです。プロンプトをベースにプログラムを作成する「Vibe Coding」は、まさにAIエージェントだからこそできることです。

以下のフローを比較すると、判断の主体の観点から、通常の対話型AIとAIエージェントの違いがよくわかります。

図：対話型AIを使った課題解決の流れ

図：AIエージェントを使った課題解決の流れ

また、Deep Researchはこの違いのわかりやすい例です。取得した情報が十分かによって自動で追加調査をするところが、一往復で留まる通常の対話型AIと異なるAgenticな挙動です。

図：Deep Researchの内部処理

このAIエージェントの考え方をコーディング（およびその周辺業務）に適用したのが、次に取り上げるAgentic Codingです。

Agentic Coding

Agentic Codingと聞くとコーディング専用のように思えるかもしれませんが、その仕組み自体はコーディングに限らず、文章執筆やドキュメント生成など幅広い領域で活用できます。

例えば以下の事例では、文章執筆の準備・発想・構造化・執筆・編集・洗練までAIをフル活用しています。

前提知識

非エンジニアの方に向けて、この先の内容を理解するために必要な前提知識を簡単に整理します。

統合開発環境（IDE）：プログラムを書くためのツール。コードの整形やデバッグなど、コーディングのための便利な機能が内蔵されていたり、機能拡張ができたりする。Visual Studio Codeが代表的
API：外部のサービスとプログラムからやりとりするための窓口。従来の生成AIの活用はAPIベースで、APIに対してpromptを送ると結果を返してくれる形であり、利用量ベースの従量課金が一般的だった
git：プログラムの変更履歴を管理するためのツール
GitHub：gitをホスティングするサービスの1つ。チーム開発のプラットフォームとして、変更履歴の確認やレビューなどを行える
開発プロセス：手元で開発・検証を行い、検証環境で確認し、検証済のものを本番環境に反映する手順。組織やサービスによって差がある

開発プロセスの例：

Agentic Codingの簡単な歴史

時期	サービス	特徴
2021年6月	GitHub Copilot	IDEの拡張機能として入力コードの補完機能をリリース。コーディングにおけるAI活用の先駆け
2023年1月	Cursor	VS Codeをカスタマイズした独自IDEで、対話型・自律駆動のAIコーディングを実現。12か月で売上が100万ドル→1億ドルへ成長
2023年9月	CodeRabbit	コードレビューに特化したAIサービス
2024年12月	Devin	Slackで指示を出し独自環境で動く完全自律型エージェント
2025年5月	Claude Code	ターミナルで利用可能なCLIツール。定額制の料金モデルにより、心置きなく使えるように（私もその1人）

現在の代表的なサービスは以下の通りです。互いに競争しながら、機能的には似通ってきています。

GitHub Copilot / GitHub Copilot CLI（GitHub）
Cursor
Devin
Claude Code（Anthropic）
Codex（OpenAI）
Gemini CLI / Antigravity（Google）
Kiro（AWS）

コーディングにおけるAI活用の形式と機能

AIコーディングツールは、「どこで動くか（形式）」と「何をしてくれるか（機能）」の組み合わせで特徴づけられます。同じツールでも形式が違えば使い勝手は大きく変わり、機能の組み合わせ次第で開発プロセスのどの工程に効くかが決まります。

まず動作形式は、ツールがどこで動き、開発者の作業フローのどこに入り込むかを示します。

動作形式	説明
IDE上（ローカル）	手元の開発環境で動作
CLI	ターミナルから操作
GitHub上	リポジトリと連携して動作
独立環境	専用の隔離環境で動作

なお、当初は1ツール1形式という棲み分けがありましたが、最近ではそれぞれが機能拡張することで1つのツールが複数の形式に対応するようになっています。

例えばCursorはIDE中心ですがクラウド実行も提供し、GitHub CopilotはIDE拡張から始まりGitHub上のCopilot Agentにも展開しています。Claude CodeもCLI主体ですが、GitHub ActionsやWeb版にも広がっており、機能的にも互いに似通ってきています。

機能はAIに何をさせるかの種類で、コード補完のようなライトなものから、Issue起点で完結する自律型まで幅があります。

機能	説明
コード補完	途中まで書くとその先を予測して補完
コード解説	既存コードの意味や構造を説明
コード生成	シングルタスクレベルのコードを生成
自律的実行	エージェントベースのコマンド実行・コード生成
コードレビュー	GitHubで変更内容に対して修正点を指摘
Issue駆動開発	GitHubで作成された課題を起点にコーディング

対話型AIとCoding Agentの違い

Coding Agentは自由度が高い分、リスクも高くなり、守らせるべきことが多くなります。

区分	対話型AI	Coding Agent
自由度	対話が基本なので狭い	非常に高くなり得る
リスク	低い	設計次第で高くなる
守らせるべきこと	特にない	プロダクトの品質を保つために、前提が多い

実際に、Coding Agentに本番データベースを消されるといったインシデントも発生しています。

また、クレデンシャルの取扱いを間違えると容易に情報漏洩のインシデントになります。

とはいえ、どこまでリスクがあるかは使い方次第です。

Coding Agentをどう制御するか

Coding Agentは、能力とリスクの両方をブーストします。スキルレベルによってそのバランスが大きく変わります。

低スキルの人
能力：　→⇒⇒⇒⇒　ブースト
リスク：→→→⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒　ブースト

高スキルの人
能力：　→→→→→⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒　ブースト
リスク：→⇒⇐⇐⇐⇐⇐⇐⇐⇐⇐⇐　スキルでリスクのブーストを抑え込める

低スキルの場合：能力は少しブーストされるが、リスクが大きくブーストされる
高スキルの場合：能力が大きくブーストされ、スキルによってリスクのブーストを抑え込める

Coding Agentは暴れ馬のようなものなので、自由度の高い使い方をしようとすると、適切に統制する必要があります。

統制の観点	手段	具体例
環境	実行環境の分離	ローカルと切り離した環境を用意する、外部通信を制限する、いきなり本番環境を変更しない
権限	最小権限の原則	危険な権限を渡さない、コマンド実行を許可制にする
ルール	ガードレールの設定	守るべきルールをツールの仕組みや、コンテキストとして渡す
プロセス	段階的な進行	仕様を明確化した上で実装に入る、gitでバージョン管理を行い途中の状態に戻れるようにする

そこで、スキルが高くない場合は、リスクの低い場面から始めるのが賢明です。

ドキュメントの作成・更新
既存コードの調査・解説やちょっとした修正
個人利用の小規模な便利ツール作成
本番運用しないプロトタイプの作成

一方で、他人のデータを利用したり他人に提供するものを作ろうとすると、そこには責任が伴います。不用意にリスクを高めないためにも、実装時は好き勝手に走らせず、設計→レビュー→調整→実装→レビュー→調整と段階的に進めることを推奨します。

段階的に進めるときのポイントはフィードバックループです。特に、エージェントが自律的にフィードバックループを回せるようにすると効率的です。これをきちんとやろうとすると、結局はエンジニアリングのスキルが求められます。

環境構築、権限管理
コード管理、バージョン管理
開発／デプロイフロー設計
アーキテクチャ設計、技術選定
静的解析／テスト
レビュー
ロギングと監視

データ領域からコーディングを始めたような人は、基礎的な知識として以下の書籍が非常に参考になります。

Agentic Codingのポイント

ベースは対話型AIと同じで、①モデル選択、②プロンプト、③コンテキスト、④アクションの4つの観点を意識する点は変わりません。前述したそれぞれの観点がどこでどう影響してくるのかを考えていくと、Coding Agentの動きを統制しやすくなります。

その上でAgentic Codingの核心は、計画→実行→評価のフィードバックループを多層的に回すことです。

設計フェーズでは、ドキュメントで対話しながら仕様を整理する方法と、プロトタイプ（動くもの）で仕様を具体化する方法を使い分けます。設計に基づいて段階的に実装を拡張し、初期開発・拡張開発のそれぞれでフィードバックループを回します。AIで実装作業が高速化するので、気に入らなければ捨てて作り直すのがやりやすいのも、対話型AIにはなかった強みです。

加えて、「作ること」と「作るための環境を整えること」を同時に回すことも重要です。メモリファイル、Rules、Skills、サブエージェント、Agent Teamsなど、Coding Agentが効果的に動くための環境は、使いながら不足を見つけて育てていきます。この環境整備自体もCoding Agentに任せられるので、利用中に感じた不足をそのまま指示すれば、Coding Agent自身が自分の動く環境を更新してくれます。

対話型AIでは会話が終わればそこで完結しますが、Agentic Codingでは「成果物」も「環境」もファイルとして残り、使うたびに改善されていきます。次のサイクルはより良い状態から始められるので、両方が継続的に育っていく点が、対話型AIにはない本質的な強みです。

こうした「成果物と環境を育てる」発想は、コードに限らず文章執筆や調査・研究、業務改善など幅広い領域にも応用できます。チャット形式で対話してガチャを回すだけの時代は、もう終わっています。

具体的な機能の位置づけ

Agentic Codingツールが提供するさまざまな機能は、対話型AIの4つの観点（モデル・プロンプト・コンテキスト・アクション）のどこに効くのかでマッピングできます。位置づけを押さえておくと、新機能が出てきたときも「どの観点を強化する仕組みか」を素早く把握できます。

機能	対応する要素	役割
メモリファイル / Rules	コンテキスト	プロジェクト知識・規約の永続化と共有
Permission	アクション	ツール利用の許可制御による実行制限
Hooks	アクション	特定タイミングでの自動処理（実行前後の検証や通知など）
MCP	アクション	外部ツール・サービスとの連携
Skills	コンテキスト＋アクション	特定タスクに特化した知識と機能の組み合わせ
サブエージェント	コンテキスト＋アクション	独自のコンテキスト・ツールを持つ下位エージェントへの委譲
Agent Teams	コンテキスト＋アクション	マルチエージェント間での相互作用の促進

大きく3つのグループに分けられます。

コンテキスト系（メモリファイル / Rules）は、AIが「何を知っている状態」を整える機能です。前述の「環境のフィードバックループ」で育てていく対象であり、プロジェクトを進めながらAIが知るべき情報を更新し続けることで、出力の質が上がっていきます。

アクション系（MCP、Permission、Hooks）は、AIに「何をさせるか・させないか」を制御する機能です。MCPで外部連携を増やす一方、PermissionとHooksでガードレールを設けることで、Coding Agentの統制で扱った権限・ルールを具体的な仕組みとして実装できます。

複合系（Skills、サブエージェント、Agent Teams）は、コンテキストとアクションをセットで提供する機能です。Skillsは特定タスクに必要な知識と機能をパッケージ化したもの、サブエージェントはメインのエージェントから独立したコンテキスト・ツールセットでサブタスクを処理する仕組み、Agent Teamsは複数のエージェントが協調してより複雑なタスクをこなす仕組みです。1つの機能で複数の観点に同時に効くため、複雑なタスクをワンセットで扱えるのが強みです。

さらに、これらの機能の多くは「ユーザー」「プロジェクト」「ローカル」の3階層で設定できる仕組みになっています。

階層	スコープ	用途
ユーザー	個人全体（マシン横断）	個人の好みや作業スタイルなど、すべてのプロジェクトに適用したい設定
プロジェクト	リポジトリ単位（gitで共有）	チームで共有するプロジェクト固有のルールや設定
ローカル	リポジトリ内・個人ローカル（gitignore対象）	個人の作業環境固有の設定や、共有したくない一時的な設定

階層が分かれていることで、チーム全体に共有すべきルールと、個人の好みに留めたい設定を切り分けて管理できます。例えばClaude Codeでは、ユーザーレベルは ~/.claude/、プロジェクトレベルは <repo>/.claude/、ローカルレベルは <repo>/.claude/settings.local.json といった形で配置されます。

また、プロジェクト内部でもディレクトリ階層に応じて設定が切り替わる仕組みが一般的です。プロジェクトルートとサブディレクトリの両方にメモリファイルを配置しておくと、作業する階層に応じて適用されるコンテキストが変わります。モノレポのように複数サービスを1リポジトリで管理する場合に、サービスごとに独自のルールを定義する用途で有効です。

より具体的な実践やセキュリティの担保の例については、別記事をご参考ください。

AIプラットフォームとAIデータ基盤

ここまではAgentic Codingを中心に、個人やチーム単位でAIをどう使いこなすかを見てきました。一方、組織全体でAIを活用しようとすると、業務アプリケーションへの統合や、全社データとの連携といった、より広いスコープの論点が出てきます。ここではその方向性として「AIプラットフォーム」と「AIデータ基盤」の2つを取り上げます。

なお、いずれも構成としてはより複雑になってくるため詳細は省略しますが、①モデル選択、②プロンプト、③コンテキスト、④アクションの4つの観点で最適化を図っていくということは共通しています。

AIプラットフォーム

※この呼称は一般的なものではなく、本記事での独自の呼称です。

業務を横断するプラットフォームとしてサービスを提供している事業者が、それらのサービスを横断するAI機能を提供しているものを指します。

Microsoft: Microsoft 365 Copilot
Google: Gemini Enterprise
Salesforce: Agentforce

プラットフォームを利用しているだけで、自然とサービス間をまたぐAI活用が進められるため、データの連携について深く意識しなくてもよいのが利点です。

一方で、以下の点には留意が必要です。

効果的に活用するにはサービス内のデータマネジメントが重要だが、そのハードルは高い
現時点では低コストに見えても、将来的には費用が高く設定される可能性がある
データやワークフローを握られるため、提供事業者へのベンダーロックインが生じる

AIデータ基盤

組織を横断するデータ基盤を、AIのデータソースやホスティング環境として利用するアプローチです。

DWH自体が非構造化データも扱えるようになっており、DWH自体が外部と連携するAIエージェント機能を持ったり、AIエージェントから自前の仕組みでDWH内のデータにアクセスさせたりすることが考えられます。

Snowflake
Databricks
BigQuery

データ活用のために整備したデータ基盤を発展的に利用でき、AI活用をサービス横断で行えて、一定のベンダーロックインを回避できるのが利点です。ただし、AIに適切にデータを扱わせるには、さまざまな工夫が必要になります。

最近は弊社primeNumberで提供しているCOMETAも急速に機能拡張しており、primeNumber社内はもちろん、ビジネス職の方を含めた多くのお客様に対してAIデータ基盤としてご利用いただいています。（宣伝）

さいごに

生成AIの成果物を統制するためのポイントを整理すると、以下の3点に集約されます。

仕組みを理解する：対話型AIの4要素（モデル・プロンプト・コンテキスト・アクション）を意識し、どこを調整すれば成果物がどう変わるかを把握すること
フィードバックループを回す：計画→実行→評価のサイクルをAIで加速させ、多層的に回すこと。実行だけでなく、計画と評価にもAIを活用すること
環境を育てる：メモリファイル、Rules、Skills、サブエージェント、Agent Teamsなど、AIが効果的に動くための環境を継続的に整備すること

チャットでガチャを回す時代から、AIと共にフィードバックループを回す時代へ。その転換を意識して取り組むことが、生成AIの成果物を統制する第一歩です。