AIエージェントに作業を任せる時間が増えるほど、会話ログだけを追うのはしんどい。
ログには全部残っている。
でも、全部残っているからこそ、あとから見るのが大変になる。
何をやったのか。
何を確認したのか。
どこまで終わっていて、何が未確認なのか。
人間が承認しないといけない点はどこか。
このあたりが、長い会話の中に埋もれていく。
2026年6月18日、Anthropicが Claude Code Artifacts を発表した。
Claude Codeの作業内容を、PR walkthrough、system explainer、dashboard、release checklist のような共有できるページにする機能。
ただ、自分が面白いと思ったのは、Claudeの新機能そのものではない。
AIエージェントの仕事を、会話ログではなく「レビューできる成果物」として残す方向に進んでいること。
ここが面白いところ。
Codex運用でも、同じ考え方はすぐ使える。
外部のArtifact機能を入れなくても、まずはMarkdownのdocs artifactで十分。
AIエージェントの作業は、会話ログだけだとレビューしづらい
AIエージェントの作業ログは、作業過程を見るには便利。
どんな前提を渡したか。
何を調べたか。
どこで迷ったか。
どのコマンドを実行したか。
こうした流れを追えるのは、会話型UIの良さ。
ただ、レビュー対象としては長すぎる。
たとえば、ブログ記事を公開する作業でも、実際には多くの工程がある。
- WordPressで公開する
- 公開HTMLを確認する
- title、description、canonical、OGPを見る
- 画像altを見る
- docsに公開履歴を残す
- Search ConsoleでURL検査をする
- はてなブックマークを登録する
- X投稿スレッドへ渡す
- 公開後の観測予定を残す
- 内部リンク候補を見ておく
これをAIに任せると、作業自体は進む。
でも、最後に人間が見るべきなのは、会話ログ全体ではない。
見るべきなのは、作業の結果。
何が完了したか。
何が未確認か。
どこに承認待ちがあるか。
次に何を見ればいいか。
ここが1枚で見えないと、AIに任せた作業を安心して受け取れない。
Claude Code Artifactsが示した「作業をページにする」方向
Claude Code Artifactsは、Claude Codeの作業を共有できるページとして出す機能。
公式記事では、作業中の内容をliveで見られるページにし、同じURLで更新し、バージョン履歴も持てると説明されている。
PRの説明、システムの構造説明、ダッシュボード、リリースチェックリストなどが例として挙げられている。
さらに、Claude Codeのsession context、コードベース、connector、会話を使ってartifactを作る、という説明もある。
これは、組織でAIエージェントを使うときには自然な方向。
エンジニアが「このagentは何を調べたのか」を会話ログで説明するのではなく、関係者が同じページを見る。
ステータス報告を人間が毎回まとめ直すのではなく、AI作業の成果物として最初から見える形にする。
ただし、注意もある。
2026年6月20日時点では、Claude Code ArtifactsはClaude Team / Enterprise向けのbeta機能。
Codexに同じ機能がある、という話ではない。
また、組織内共有、connector context、アクセス管理も絡む。
個人のCodex運用に、そのまま外部サービスとして入れる必要はない。
この記事では、Claudeの機能紹介ではなく、その考え方だけをCodex運用に持ち込んでいる。
Codex運用なら、まずdocs artifactで十分
自分のCodex運用では、外部のArtifact機能を使わなくても、Markdownのdocsで足りる。
ポイントは、見た目のリッチさではない。
作業が終わったあと、人間が判断するための情報が1枚にまとまっていること。
たとえば、記事公開後の作業なら、Blog Release Artifact という1枚のメモにする。
そこに、公開URL、確認済み項目、未確認項目、承認待ち、外部送信、出典、残タスク、次に使う手順をまとめる。
これだけで、会話ログを全部読まなくても判断しやすくなる。
Codexの作業は、長くなることがある。
途中で公開確認をして、docsを更新して、別スレッドへ通知して、さらに残タスクを整理する。
このとき、最後に欲しいのは「頑張りました」という報告ではない。
欲しいのは、確認できる成果物。
Blog Release Artifactに入れる項目
自分が使いやすいと感じているのは、素朴な形。
公開向けに短くすると、こんな感じ。
# AI作業Artifact: <作業名>
- 目的:
- 完了したこと:
- 確認済み:
- 未確認:
- 承認待ち:
- 外部送信:
- 使った出典:
- 触っていないもの:
- 次にやること:記事公開後の作業なら、もう少し具体的にできる。
# Blog Release Artifact: <記事タイトル>
- URL:
- 公開確認:
- publication check:
- docs同期:
- X通知:
- Search Console:
- はてなブックマーク:
- 公開後の観測予定:
- 内部リンク候補:
- 残タスク:
- 次に使うskill:大事なのは、全部を自動化することではない。
「確認済み」と「未確認」を分ける。
「完了」と「承認待ち」を分ける。
「AIがやったこと」と「人間が見ること」を分ける。
これだけで、作業後の不安が減る。
特に公開作業では、外部に影響する操作がある。
X投稿、Search Console、はてなブックマーク、既存記事の書き換えなど。
こういうものは、AIに全部任せるかどうか以前に、状態を見える化した方がいい。
送ったのか。
送っていないのか。
送れなかったのか。
次に人間が判断するのか。
この粒度で残っていれば、あとから迷いにくい。
Artifactは、自動化の代替ではなくレビューの土台
Artifactを作ると聞くと、きれいなダッシュボードや、共有ページを想像しがち。
でも、自分の運用では、まずそこまでいらない。
最初に必要なのは、AI作業の受け取り方を決めること。
会話ログを全部読むのか。
要約だけ読むのか。
それとも、確認済み項目と残タスクが分かれた成果物を見るのか。
自分は、3つ目が一番実務に合っていると感じている。
会話ログは、必要なら戻れる場所。
Artifactは、判断するための場所。
この2つを分ける。
AIエージェントが作業者として動くなら、人間は作業ログの読者ではなく、成果物のレビュー担当になる。
だから、Artifactには見栄えよりも、判断に必要な項目が必要。
- 何を目的にした作業か
- 何が終わったか
- 何を確認したか
- 何が未確認か
- どこに承認が必要か
- どの出典を使ったか
- 何に触っていないか
- 次に何をするか
このくらいでいい。
むしろ、最初から大きくしすぎない方が続く。
機密情報を残さないこともArtifactの役割
Artifactには、何でも残せばいいわけではない。
公開記事の下書きや作業報告として残すなら、機密情報、認証に関わる情報、アカウント固有の情報、内部だけで使うURLは出さない。
公開後の観測予定も、細かい内部構造まで出す必要はない。
公開向けには、こう言い換えれば十分。
- Search Consoleで確認する
- 公開後の観測予定を残す
- 7日、14日、28日で見る
- 内部リンク候補をあとで確認する
- 必要ならtitleやdescriptionを見直す
どのシートのどの行か。
どの内部の識別情報か。
どの内部向けURLか。
そういう情報は、読者にもAIにも不要。
Artifactは、情報を全部出す場所ではない。
人間が判断するために、必要な情報だけを残す場所。
小さく始めるなら、公開後チェックから
いきなり全作業をArtifact化しようとすると、たぶん続きません。
最初にやるなら、公開後チェックが向いている。
理由は単純。
毎回やることが似ている。
確認項目がはっきりしている。
外部送信や承認待ちが混ざりやすい。
あとから見返す価値がある。
ブログでなくても同じ。
アプリのリリース。
PRレビュー。
AI調査。
MCP候補の安全確認。
デザイン案の比較。
どれも、最後に「何を見れば判断できるか」を1枚にできる。
AIに任せる作業が増えるほど、プロンプトよりも、受け取り側のフォーマットが大事になる。
何を頼むかだけでなく、何を成果物として受け取るか。
ここを決めておくと、AI作業はだいぶ扱いやすくなる。
まとめ。AI作業はログではなく成果物で受け取る
Claude Code Artifactsは、AIエージェントの作業を共有できるページにする方向を示した。
ただ、自分のCodex運用では、外部サービスを増やす前に、まずdocs artifactで十分だと思っている。
会話ログは作業過程。
Artifactはレビュー対象。
この2つを分けるだけで、AIに任せた仕事を受け取りやすくなる。
AIエージェントに作業を任せるなら、最後にこう聞くようにしたい。
作業ログを見せてほしい。
ではなく、
レビューできる成果物としてまとめてほしい。
この方が、人間は判断に集中できる。
関連する記事
- AIに任せる仕事は、プロンプトではなくskillにした方がいい
- 人間が伝言係をやめると、AI開発チームはかなり自動化できる
- Codexのthread toolで、AIチームの役割スレッドをつなぐ
- Codexのレート制限リセット機能？30日期限にご注意を