VS Code でエージェント型 AI と働く仕事環境 (IDE) の勧め ---- 還暦を過ぎた英語教師から非エンジニア系の大学生に送る

 

 

 

  

この記事で得られるもの：ウィンドウを行き来せずに、一つの画面で調べ物も執筆も AI との作業も完結する環境。

費用：VS Code は無料です。AI の契約は有料ですが、無料の範囲だけでも始められます。

今日かかる時間：15 分。

 

気が散らない仕事場

文章を書いていて、こんなことはないでしょうか。

調べ物をしようとブラウザーを開く。ついでに X/Twitter を見る。誰かのブログに飛ぶ。メールも確認しておこうと思う。——気がつくと、自分が何をやっていたのか分からなくなっている。あるいは、あるウィンドウで作った文章をコピーして別のウィンドウに貼り付け、また戻り、を延々と繰り返している。

私が皆さんに勧めたいのは、この行ったり来たりを無くす環境です。左にフォルダー構造、真ん中に自分の書いている文章、右に AI。この三つが一つの画面に並んでいて、その画面から出る必要がありません。

私は初めてこの環境を使ったとき、午前中ずっと集中して仕事ができました。この集中度には自分でも驚きました。

先に一つ言っておきます。私はプログラミングをしません。これから紹介する VS Code はエンジニアが使う道具ですが、このアプリで書くことにコードの知識は一切要りません。VS Code を「文章を書き、考えるための、とても出来のよい場所」として使う話です。

 

エージェント型 AI とは何か

「エージェント型 AI」という言葉を当たり前のように使いますが、これまでのチャット型 AI との違いがはっきりしない方もいるでしょう。

私がよく使う喩えで言えば、こうです。歩いていた人間にとって、パソコンの登場は自転車を手に入れたようなものでした。そこにチャット型 AI が加わり、原付二輪車になりました。ずいぶんパワーアップしたわけです。そして 2026 年ごろから世界的に普及したエージェント型 AI は、車です。原付とは比べものになりません。

人間関係でたとえるなら、チャット型 AI は会社の先輩です。わからないことを聞けば、ある程度のことは教えてくれます。しかし実際に作業をするのは皆さん自身です。

エージェント型 AI は皆さんの部下、あるいは外部の業者です。ですから皆さんの主な役割は、明確な指示を出すことになります。チャット型 AI が一問一答だったのに対し、エージェント型 AI で皆さんが行うのは依頼、あるいは発注です。そして AI が最終的に返してくるのは納品、つまり仕事の完成品です。

その途中で交わす会話を、一つの画面の中で行えるようにする——それが以下で述べる環境です。

代表的なものを挙げておくと、Claude なら Claude Cowork と Claude Code、ChatGPT なら ChatGPT Work と Codex があります。前者二つが軽自動車、後者二つが普通乗用車といったところでしょうか。この記事で扱うのは後者、Claude Code と Codex です。

 

VS Code を勧める理由

VS Code（無料）を勧める理由は三つあります。

https://code.visualstudio.com/

第一に、Markdown を扱うのに非常に便利だからです。 Markdown は、いくつかの記号を使っただけのとても簡単なメモ形式で、AI と人間の共通メディアと言ってよいものです。ただ、ふつうのテキストファイルに書くと記号が並ぶだけで見にくく、かといって Word を使うほどのものでもありません。VS Code なら Markdown の記号が色付きで表示され、構造が一目で分かります。ファイル自体も非常に軽いので、ハードディスクの負担になりません。

第二に、使い方が世界中で確立しているからです。 初めて見ると画面がたくさんに分割されていて驚くかもしれませんが、分からないことは検索すればほぼ必ず答えが見つかります。

第三に、無料だからです。 Microsoft 社が提供しているので、信頼性の点でも安心できます。

 

費用と、無料でできること

VS Code そのものは無料ですが、Claude Code や Codex を使うには各社との契約（有料・月額20米ドル程度）が必要です。

ですから、順番を分けて考えてください。

・無料でできること：VS Code を入れ、Markdown で文章を書き、フォルダー構造を整える。ここまでで、集中できる仕事場は手に入ります。

・有料が必要なこと：AI の拡張機能を右側の枠で動かすこと。

先に無料の部分だけを一週間使ってみて、「この画面で仕事をするのは快適だ」と思えたときに、初めて契約を考えれば十分です。私自身、あれもこれもと AI にお金を使うのではなく、いま持っている契約でできることを掘り下げる方針を取っています。とはいえ、ClaudeかChatGPTの有料契約は、未来への投資と考えれば私は十分に価値があると思っています。

 

VS Code の画面構成

〈図1〉VS Code の画面構成。左に EXPLORER、中央にエディター、右に AI、中央下は `_WorkLog.md`。

最初は簡単に考えておけば結構です。

・一番上：「File」「Edit」などのメニュー。どのアプリにも共通ですから説明は要らないでしょう。

・左端：フォルダー構造。なぜここにフォルダーが、と最初は思うかもしれません。しかし AI と作業をしていくと、いま扱っているファイルがどのフォルダーにあるのかという情報が決定的に大切だと分かってきます。消すこともできますが、まずはそのままに。

・中央：エディター。文章をどんどん書いていくところです。

・右：AI。拡張機能を入れると、ここに AI が現れます。

・下：ターミナル。コンピューターの最も深い部分から操作するところです。しばらく使わないと思います。私はこの領域をターミナルとしてではなく、作業用ファイルを開く場所として使っています（後述）。

要は、左にファイル構造、真ん中にエディター、右に AI。これだけ覚えておけば十分です。

 

わからないことの調べ方

画面に圧倒されて手が止まったら、Google app for desktop を起動し、「画面を共有」を指定してください。VS Code の画面がそのまま共有されますから、「これこれをしたいのですが、どうしたらいいですか」と聞けば、すぐに教えてもらえます。設定の質問も、機能の質問も、これで大半は片づきます。

なお Google app for desktop は Windows 用のアプリです。

https://search.google/google-app/desktop/

Mac では名称が変わり、Gemini アプリになります。

https://gemini.google/mac

画面共有ができる点は同じですので、以下「Google app for desktop」とあるところは、Mac の方は「Gemini アプリ」と読み替えてください。

覚えておくと便利なのが、command palette です。Ctrl + Shift + P、あるいは F1 キーで開きます。VS Code の機能はほぼここから呼び出せますから、いろいろ試してみるとよいでしょう。

設定の際に JSON と呼ばれるコードの記入を求められることがありますが、心配は要りません。「これこれをしたいので JSON コードを書いてくれ」と頼めば書いてもらえます。それを指定された場所に貼り付けるだけです。

とはいえ、たくさんの機能が必要なわけではありません。最初に整えるとよいのは、Markdown の記号が色付きで表示されるようにすること、Markdown ファイルとしてすぐ保存できるようにしておくこと、フォントの大きさを決めること、この三つくらいでしょう。dark mode と light mode は好みで、いつでも切り替えられます。

一点だけ提案があります。VS Code の操作画面は日本語に変換できますが、英語のままにしておくことをお勧めします。コンピューターや AI の用語は英語が主流ですから、早いうちに慣れておく方が得です。

 

拡張機能——Claude Code と Codex の導入

中央のエディターだけで文章を書くことに慣れてきたら、左端のアイコンから「拡張機能」を開きます。ここから Claude Code と Codex（ChatGPT を出している OpenAI 社のエージェント型 AI）を導入できます。必ず Anthropic 社と OpenAI 社が提供している公式の拡張機能を選んでください。それぞれ一つずつダウンロードして登録すれば、契約を持っている限りただちに使えます。これで AI 入りの統合開発環境、IDE（Integrated Development Environment）の出来上がりです。

ここで一つだけ、先に守っておいてほしいことがあります。 エージェント型 AI は皆さんのパソコンの中のファイルを実際に読み書きします。ですから、最初は空のフォルダーを一つ作り、その中だけで試してください。卒業論文の唯一のコピーが入っているフォルダーを、いきなり AI に開かせてはいけません。AI が間違った作業をしたとき、既存のファイルを壊してしまうことがありえます。触らせる範囲をどう決めるかは、後の節で詳しく述べます。

もう一点。Dropbox などのクラウド同期フォルダーの中で AI に作業させると、同期の衝突という別種の問題が起こります。慣れるまでは、同期されないローカルのフォルダーで試すのが安全です。

 

エディターと AI の直結

フォルダー構造でファイルを適切に指定すれば、中央のエディターに書かれていることを右側の AI がそのまま参照できます（以下は Claude Code を中心に説明します）。

たとえば文章を書いていて、調べたいことが出てきたとします。右側の AI に検索や調査をさせ、結果を出力欄に出させる。それをコピーしてもいいですし、指示の仕方によっては、AI の出力を直接エディターに書かせることもできます。

さらに便利なのが、選択範囲の受け渡しです。中央で書いている文章をカーソルで選択すると、Claude Code 側に「一部が選択されている」という表示が出ます。その状態で AI の入力欄に例えば "reply" とだけ入力すれば、AI は反転表示された部分をそのまま読んで実行します。コピー＆ペーストすら要りません（残念ながら、現在の Codex 拡張機能にこの機能はありません）。

この右側の AI はウェブ検索もできますし、皆さんのローカルファイル、つまりパソコンの中のファイルも読めます。Word で書きながらブラウザーとエクスプローラーを行き来していた頃とは、作業環境の強さがまったく違います。

 

チャット言語とファイル言語

AI とやりとりする言語を「チャット言語」、AI が作るファイルや皆さんが AI に読ませるファイルの言語を「ファイル言語」と呼んで区別すると便利です。

チャット言語を英語にすると、AI の返答の表現を使って返事をすることになりますから、単語も表現も英語の発想法も自然に身についていきます。強くお勧めします。

その上で注意が必要なのは、チャット言語が英語でも、ファイル言語は日本語である場合があることです。この区別を明示しておかないと、AI が勘違いしてチャット言語のままファイルを出力してしまいます。

 

@ によるファイル指定

IDE で AI とやりとりするとき便利なのが、アットマーク（@）です。@ を付ければ、AI は指定されたファイルやフォルダーを読み取ります。

ですから @ 付きのファイル名を並べて「このファイルとこのファイルとこのファイルを比較した上で出力してください」と言えば、複数のファイルを自動的に読んで仕事をしてくれます。AI の入力欄で @ の後に文字を打ち始めると候補が表示されるので、名前を正確に覚えている必要もありません。

文脈が十分に共有されていれば、「さきほどあなたが作ったファイル」といった日常的な言い方でも通じることがあります。ただし、やりすぎは禁物です。明確な指示を基本にしてください。これは人間同士のコミュニケーションでも同じことです。

 

ファイル名と半角・全角

ファイル名やフォルダー名は、できるだけ英語で、半角で、空白を入れずに付けることをお勧めします。

名前に空白を入れないのは古くからのコンピューター業界の流儀です。Word のような一般ユーザー向けアプリでは空白が許容されるようになりましたが、AI に扱わせる場合は、いまも空白なしが求められる場面が多くあります。

半角の徹底は Markdown 記号でも同じです。たとえばシャープ記号（#）のすぐ後ろに文字をくっつけて書くと、見出しとして認識されません。全角の記号で Markdown 記号を打った場合も同様で、色がハイライトされません。日本語では半角と全角を使い分けなくてはならず、ここが実に面倒なところです。

Windowsパソコンでの切り替えはキーボード左上の半角／全角キーで行いますが、これが押しにくい。Windows パソコンで右手と左手の親指だけで切り替える方法を書きましたので、よければ読んでみてください。（Mac の方は「英数」「かな」キーがすでに親指の位置にありますので、この工夫は要りません。）

 https://x.com/yosukeyanase/status/2080237994301345936?s=20

 

`_WorkLog.md` ——プロンプトの下書き場

ここは、私がとても便利に思っている習慣です。

私は AI への入力（プロンプト）が長くなりそうなときは、まず `_WorkLog.md` というファイルに下書きします。中央のエディターを上下に分割し、上を書いている文書ファイル、下をこの `_WorkLog.md` にするのです。

表記についての補足：「`」（バッククォート）で囲むのは、ファイルやフォルダーの名前をそのままの形で正確に示すための記号です。またファイル名の先頭に「_」を付けるのは、そのファイルをフォルダーの一番上に表示させるための工夫です。

下書き用のファイルを別に持つ理由は三つあります。

・AI のチャット入力窓は小さすぎる。書いた文章を読み返すことが難しく、落ち着いて考えられません。

・誤送信が起きる。日本語で書いていると、変換候補を確定したつもりで Enter を押してしまい、未完成のプロンプトが飛んでいきます。`_WorkLog.md` ならその心配がありません。

・AI の長い出力を見ながら書ける。右側の出力欄の該当箇所を見ながら、下のエディターで自分の文章を組み立てられます。入出力欄だけでやりとりしていると、AI の回答と自分の入力欄の間を何度も往復することになり、これが地味に効きます。

つまりこのファイルは、思考をゆっくり進めるための場所です。ターミナルを使わない私たち非エンジニアにとって、画面下の領域の実用的な使い道でもあります。

画面の分割方法：エディター部分の上にある「画面が二つに分かれたアイコン」を押すと左右に分かれます。上下に分けたい場合は、Alt を押しながら同じアイコンを押してください。`_WorkLog.md` は下でも横でも、好きな方で構いません。

 

AI に触らせる範囲と、フォルダー構成

エージェント型 AI を自分のパソコンで使うなら、どこまでを AI に触らせ、どこから先は触らせないかを決めておく必要があります。決めていないと、AI が誤作動したときに既存のファイルを壊しかねません。

そしてこれは、単なる安全対策ではありません。フォルダー構造を考えることは、自分の仕事をどう分析するかということです。自分の仕事は大きく分けるといくつになるのか。その一つ一つは、さらに細分化するとどうなるのか。そういう問いです。

私はエージェント型 AI を使うまで、`研究`、`教育`、`行政`、`生活` の四つを主なフォルダーとしていました。エージェント型 AI を使い始めてからは、AI にファイルを作成・編集させてよい領域を上記の4つのフォルダーと並行して設置した `AIWorkspace` というフォルダーにまとめています。Claude Code のワークスペース (`ClaudeWorkspace`) の中には `MySecondBrain` を入れていますが、これについては別の記事に書きました。

https://yanase-yosuke.blogspot.com/2026/06/claude-cowork-obsidian.html

 

Scratchpad、Temporary、Project——三種類の作業場

私のワークスペース（`ClaudeWorkspace`, `CodexWorkspace`）には、主に三種類のフォルダーがあります。前提として、私は `AIWorkspace` 全体をAI専用の作業場と考えています。仕事が完成したら、成果物は必ず AI 領域の外、つまり研究・教育・行政・生活のどこかのフォルダーに移します。

・`Scratchpad`：10 分か 30 分で終わる臨時の作業をする場所。

・`TemporaryFolder`（`ClaudeTemp01`, `ClaudeTemp02`,  `CodexTemp01`, `CodexTemp02`など）：数日で終わる仕事の場所。会社で言えば会議室 1、会議室 2 でしょうか。会議室はどの部門でも予約すれば使えますが、終わったらすぐ空けなくてはなりません。ですから仕事が終わったら、完成品は所定のフォルダーへ移し、不要なファイルは処分して、きれいに空にします。

・プロジェクトフォルダー（`ClaudeProjects`, `CodexProjects`）：数週間から数か月かかる仕事の場所。その下にサブフォルダーを作り、たとえば `2026-08-22-OkayamaPresentation` のような名前で関連ファイルを貯めていきます。会議室ではなく、営業部や経理部のように特定の部署がずっと使い続ける部屋にあたります。

この三つの区別があるだけで、ファイルが散らかりません。

 

おわりに——最初の一歩

長々と書きましたが、やることは段階に分けられます。

今日（15 分）

VS Code をインストールする。フォルダーを一つ開く。`_WorkLog.md` という名前のファイルを作って、一行書いてみる。今日はこれで終わりです。

今週

何らかの文章の下書きを、その VS Code の中で書いてみる。Markdown の記号（`#` と `-` の二つで十分です）を使ってみる。分からないことは Google app for desktop に画面を共有して聞く。

慣れてきたら

拡張機能から Claude Code か Codex を入れる。まず空のフォルダーで試す。エディターを上下に分けて `_WorkLog.md` を持つ。

ここまで読んで分かってきたかもしれませんが、AI を使うことは単なるテクニックではありません。自分の仕事をどう分析するか、自分の頭脳と集中力をどうマネジメントするかという問題です。フォルダー構造を考えることも、プロンプトを下書きすることも、突きつめればそこに行き着きます。

そして最後にもう一度だけ。できれば AI とのチャット言語を英語にしてください。AI の用語はほとんどが英語ですから、AI を英語で使えば、英語と AI を掛け算で上達させることができます。皆さんの将来の可能性が大きく広がります。

集中して仕事をし、終わったら休むなり遊ぶなり、豊かな時間を過ごしてください。そのための環境です。

 

〈補足〉VS Code とよく似た構造を持つ Cursor という IDE が、現在たいへん人気を得ています。私も導入を検討しないわけではありませんが、まずは手元の Claude Code と Codex を載せた VS Code でできるだけのことをやろうと考えています。私も少しずつ、仕事のやり方を学んでいるところです。

 

追記：この文書は、別ファイルで説明したHAHA原則に基づいてAIを利用し、最終的に私自身が判断して作成したものです。

『判断力批判』要約作成におけるエージェント型AI (Codex in VS Code) との協働記録

 

非エンジニアの私が、なんとかエージェント型AIを使おうとしている過程をここで報告します。

1. 出発点：私はAIに作業を委ねる前に、目的と方法を設計した

私は、カント『判断力批判』を、現在進行中の仕事のために日本語訳・日本語解説・英語訳を少しずつ読み進めている。だが時に議論の骨子を十分に掴めないような感覚を拭えない。

私はこの古典を、今回の目的だけでなく、将来にも使える確かな知識基盤として理解したい。AIエージェントの進展により人間の「判断」が大事になると言われている現代、この古典をしっかり理解しておくことには大きな意義があるだろう。

そこで、AIにこの本をセクションごとに要約してもらうことにした。しかし、すぐ要約を書かせるのではなく、まず「どのような要約を、どのような基準で、どの順番で作るか」という作業工程をAIと一緒に設計した。要約は一つ一つのセクションごとに作るものであり、それらがシリーズとなり『判断力批判』をまとめるものとなる。

この段階で重要だったのは、AIへの依頼を単なる命令ではなく、協働作業のための設計図にしたことである。また、各要約には、大学院レベルの説明と平易な説明、重要語のドイツ語、本文内の関係、カントの他著作との関係、外部の思想史的文脈、解釈上の留保などを含めることにした。専用フォルダには、Project Gutenbergでダウンロードした『判断力批判』のドイツ語原文も入れ、AIに参照させるようにした。

また要約は英語で行うものとした。AIの知識基盤においては、カントについても英語の方が日本語よりもはるかに情報が多いとだろうと考えたからだ。それに伴い要約ファイルの言語（ファイル言語）だけでなく、AIとのコミュニケーション言語（チャット言語）も英語にした。コミュニケーションの際には、自分の考えをまとめるために、チャットの入力欄ではなく、別ファイル（作業ファイル）に英語を書いた。なお今回のAIはCodex (ChatGPT) とし、それをVS Codeの中で使った。

Yosuke YANASE　（柳瀬陽介）

@yosukeyanase

·

Jul 13

VS Codeで実現できるIDEは非エンジニアも取り入れよう--画面切替やコピペが不要になると集中力が高まる

Claude CoworkからClaude Codeに変えて10分もしないうちに、VS Codeを導入した。これは下の記事に書いた通りである。 Claude Codeを少し触っていただけで、VS Codeで、IDE（Integrated Development...

https://x.com/yosukeyanase/status/2076526907051663503?s=20

2. 「再利用可能なプロンプト」を先に作った

最初に、『判断力批判』を最後の節まで要約するために、繰り返し使える要約作成用プロンプト（reusable prompt）を作成した。といっても私がやったことは、最初に、Goal, Context, Constraintsなどを述べ、それらの条件でAIにプロンプトを作ってもらったことに過ぎない。

このプロンプトは、単に「要約してください」と指示するのではない。原典の範囲を確認し、学術的説明と平易な説明を区別し、引用・ページ番号・学説を捏造しないこと、解釈と本文上の主張を混同しないことなどまでを定めた作業手順である。

その後、このプロンプトをAIに依頼して、毎回「次は第何節か」を人間が入力しなくても、要約フォルダを調べて「まだ要約されていない次の単位」を選ぶ方式に改良してもらった。また、ファイル名の先頭に三桁の連番（serial number）を置くことも私から提案した。AIは作成するファイルには、`Draft` と `Approved` という状態表示（metadata status）を使うなど、実にさまざまな細かな提案をしてくれた。このあたりは、エージェント型AIと本当に協働で仕事を進めている感覚である。

3. AIの出力は、最初から正解として受け取らなかった

最初の試行として、序文（Preface）の要約を作成した。その後、序論の第I節から第IV節までを一つずつ作成し、その都度、私が読み、問題点を指摘し、承認したものだけを `Approved` にした。

これは、AIが長い文章を一度に大量生産する方法とは異なる。小さな単位で出力し、人間が読んで判断し、必要なら修正する。もちろん、AIの技術としては、本の最初の節から最後の節まで一気に作業することはできる。だが、私はAIの出力を少しずつ確認する方法を選んだ。こうすることで、AIの出力が少しず私の目的、読解の水準、表現の好みに合うものになっていく。あるいはAIの出力が私の意図から離れていくことを防ぐ。

今回、序文、序論第I節、第II節、第III節、第IV節まで、5本の要約を1つずつ私が読み、いくつかの応答を経て、それらを承認した。

4. 平易な説明は、単に短くすればよいわけではない

序論第I節の「一文による平易な要約」（One-Sentence Plain-Language Summary）については、私の側から「浅く、分かりにくく、この節の大きな構図を捉えていない」と指摘した。

当初の文は、ある限定的な点だけを述べていた。しかし、その節の中心は、哲学を「理論」と「実践」に分ける原理が、単なる「考えること」と「行為すること」の区別ではなく、自然（nature）と自由（freedom）という異なる原理にある、という点だった。

そこで私はAIに、まずなぜ失敗したかを分析し、修正計画を提示させ、その修正を操作ファイルに反映させた。

5. AIの出力は、もっともらしくても検証が必要だった

作業の途中で、私はAIの訳語について二度問いただした。

第一は、*Urteilskraft* をAIが単に “judgment” としていたこと、第二は*Zweckmäßigkeit der Natur* の訳語をAIが “formal purposiveness of nature” としていたことである。

AIは、この二つの問題を認め、既存の要約を修正した--AIと私では、英訳については可能な限り、私が読み進めようとしているケンブリッジ版（Cambridge edition）を使うことで合意をしていた。また、私はAIにこの種の単純ミスが生じた理由を考えさせ、再発防止策を操作ファイルに書かせた。

6. 「原典第一、既存要約第二」という原則を作った

また私は、AIが以前に作った要約を次の要約のために参照しているのかと問うた。参照すれば、全体の一貫性は上がるが、AI自身の理解を自己強化してしまう危険もあるのではないか、と問うた。

この問いから、AIは次の原則を提示した。

> 原典第一、要約シリーズ第二（source first, series second）

新しい要約を作るとき、AIはまず対象となるカント本文と、その直前・直後の文脈を読む。その後で、用語の一貫性や前後関係を確認するために、直前の一、二本の承認済み要約を参照する。先行要約は便利な補助手段ではあるが、原典より強い根拠にはしない。

この原則は、AIとの協働において重要である。過去のAI出力を「知識」として蓄積するだけでは、誤りもまた整然と蓄積される可能性があるからである。

7. AIのための「参照ガイド」を、人間の修正履歴から作った

数本の要約を作った後、`CPJ-Summary-Reference-Guide.md` という参照ガイド（reference guide）をAIに作成させた。このファイルは、今後のAIの作業を安定させるための運用規則である。AIの出力だけでなく、私からの修正と承認の履歴を、今後の作業の質を高める資源に変えた。

8. 作業のルール自体をプロジェクトに保存した

さらに、この『判断力批判』要約プロジェクト固有の `AGENTS.md` をAIに作成させた。これは、AIが後日このフォルダで再開するときに読む作業指示書である。

そこには、原典の優先順位、翻訳の検証、要約の連番、`Draft` と `Approved` の区別、13の見出し、承認済み要約を無断で書き換えないこと、大量生成をしないことなどが記されている。

AGENTSファイルは、ユーザーにとってありがたい。AIとの協働では、人間が毎回すべてを記憶しておく必要はない。重要な判断を、短いファイルに外在化（externalize）しておけば、後の作業でもAIは同じ水準を保ちやすい。

9. ファイル整理も重要

要約そのものに直接関係しない研究メモ、論文草稿、関連文書は `Supporting-Research-and-Ideas` というサブフォルダに移した。他方、カントの原典、要約作成プロンプト、参照ガイド、作業ログ、プロジェクトのルートに残した。AIが作成した要約ファイルはその前から独自のサブフォルダに入れさせていた（このサブフォルダはそのままコピーすれば、他のAIモデルにとっても利用できる情報源となる）。

こういったフォルダの整理で、AIが次に読むべき資料と、背景として保存すべき資料を区別することで、作業の焦点を保つことができる。なおこれらの作業も私が手作業でファイル移動をしたりフォルダ名を決めて記入したりするのではなく、すべてAIにさせた。

10. この協働での作業分担

この作業で私が担ったのは、単なる最終チェックではなかった。私は、目的を定め、要約の構造を決め、訳語の違和感を発見し、AIの説明が浅い理由を問い、修正の基準を作り、何を承認するかを判断した。

AIが担ったのは、長い原典の構造化、複数の読者層に向けた説明の下書き、ファイルの連番管理、作業規則の文書化、形式的な点検などであった。

したがって、この経験は「AIに要約を作らせた」という話ではない。人間が問いと基準を持ち、AIを限定された支援者として使い、出力を批判的に読み直し、より良い作業環境を段階的に作った経験である。これは、学習における「人間が最初に考え、AIを途中で使い、最後に人間が判断する」（Human-first, AI-second, Human-last）という原則の具体例として説明できる。

Yosuke YANASE　（柳瀬陽介）

@yosukeyanase

·

9h

HAHA: Human-first, AI-second, Human-last Agency

AI使用の原則を定め、AI時代の人間的主体性を育む 【この記事は、私がセメスター終了後に学生に提示した補助資料です】...

https://x.com/yosukeyanase/status/2082248139055276527?s=20

補記

今皆さんが読んでいるこの文章の下書きは今回のセッション（001-005の要約ファイルの作成）終了間際にAIに作らせました。チャットボックスには私とAIの間のコミュニケーション記録が残っているのだからAIにとっては簡単な作業です（他方、私はそういったまとめには時間をかけたくありませんでした）。しかし、AIの文章は、視点が時にAI、時に私になったりして、ぶれていたので、私が加筆修正しました。

なお、私はこの作業を深い考えなしに私がCodexでよく使っているChatGPT 5.6 Terraで行いましたが、最後に尋ねると、この種の作業なら、SoraがよいとTerraは答えたことも付記しておきます。