2026-08-09

AIの作業場はブラウザからローカルフォルダへ

ChatGPTやClaudeを毎日使っているのに、思ったほど仕事が速くならない。もしそのAIがブラウザのタブの中だけで動いているなら、原因は聞き方の上手下手ではありません。AIを動かしている場所のほうです。

ブラウザのチャットは、タブを閉じれば会話ごと消えます。良い回答が出ても、残るのは手元にコピーした文章だけです。一方、デスクトップアプリやCLIから使うAIは、パソコンのフォルダを直接読み書きします。作業の結果がファイルとして残り、次の相談はその続きから始まります。この差は、使い込むほど開いていきます。

この記事の結論: 調べ物だけならブラウザのチャットで十分です。業務として一定の品質で回したいなら、手順とデータをフォルダに置き、変換と点検をコードに任せ、それをチームのリポジトリで共有する——という運用に移る必要があります。

Webのチャットだけ、手元のフォルダで動かす、チームのリポジトリへ、という3段階と、フォルダの中身・Markdownを使う理由・zipとリポジトリの使い分け・よくある誤解をまとめた手書き風インフォグラフィック
この記事の答え — 会話で消える段階から、会社に残る段階まで

この記事は、次の順で進みます。いまどこにいて、次に何をするかの地図として見てください。

STEP 1 ブラウザで聞く いまここ。調べ物はこれで足りる
STEP 2 手元で動かす デスクトップアプリ・CLIに移す
STEP 3 フォルダに残す 素材と成果物が積み上がる
STEP 4 手順をスキルにする 品質を人の記憶から切り離す
STEP 5 リポジトリで配る チームの資産として更新し続ける

同じAIを使っているのに、なぜ差が開くのか

ブラウザやスマホのチャットは、1回のやり取りで完結するように作られています。タブを閉じれば会話は消え、次に開いた画面は前回のことを知りません。だから毎回、同じ前提を貼り直すところから始まります。会社の説明、扱っている商材、書式のルール、前回どう直したか。この貼り直しが、業務でAIを使うときの時間の大半を占めます。

「プロンプトが上手い人は結果が違う」とよく言われます。ただ実際に差を生んでいるのは言い回しではなく、渡している前提の量と正確さです。そしてブラウザのチャットでは、その前提を毎回人間が手で運んでいます。運べる量には限りがあるので、AIの側は毎回、断片的な情報から推測して答えることになります。回答がぶれるのは当然です。

Webのチャットだけで使っている限り、AIの実力のごく一部しか引き出せていない——というのが弊社の実感です。数字で測れる話ではありませんが、少なくとも「同じモデルなのに、隣の人の成果物のほうが明らかに整っている」という現象は、多くの場合ここで説明がつきます。

ChatGPTの入口が変わった — Chat・Work・Codex

この1年でツール側も変わりました。OpenAIは2026年7月9日にCodexアプリを新しいChatGPTデスクトップアプリへ統合し、7月16日にはmacOS・Windows版を全プラン向けに更新して、ChatGPTとCodexを行き来するグローバルな切り替えを入れています。ChatGPT側はさらにChatとWorkに分かれました。

入口

何をするところか

Chat

短い質問と下調べ。従来のチャット体験に近い。 会話の中で完結する。成果物を残す前提ではない

Work

仕事のタスクを最初から最後までやり切らせる。 調べる・作る・直すが一続き。成果物を置く場所が要る

Codex

ソフトウェア開発向け。デスクトップに加えてエディタとターミナルでも動く。 複数のリポジトリをまたいで変更を確認できる

注目すべきは、ChatとWorkの線引きが「難しさ」ではなくやり切るかどうかで引かれていることです。そして最後までやり切らせるには、途中の成果物を置く場所が必要になります。だからWorkもCodexも、ローカルのファイルとフォルダを扱えることが前提になっています。開発者向けに生まれたCodexの作法が、そのまま業務向けの入口の隣に並んだ、と見ると分かりやすいと思います。

Anthropic側も構図は同じです。Claude Codeはターミナル・エディタ・デスクトップアプリ・ブラウザのどこからでも使えますが、共通しているのは「手元のコードとファイルを読んで、実際に書き換える」という点です。名前にCodeと付いていても、扱う対象がプログラムである必要はありません。

「CLI」は黒い画面のことではありません。 ここでのCLI／デスクトップアプリは、ローカルのパソコンで動く版の総称です。いまはどれも普通のアプリの画面から使えます。ブラウザで開くWeb版との対比だと考えてください。

フォルダがAIの記憶になる

ローカルで動かすと何が変わるのか。ひとことで言えば、AIの作業結果が置き場所を持つようになります。同じ相談を3回した場合の違いを並べてみます。

左はWebのチャットで、1回目から3回目まで毎回前提を説明し直し、残るのは手元にコピーした文章だけ。右はローカルのフォルダで、結果がファイルとして残り、次の相談が前回の続きから始まる
3回相談したときの差 — 消えていくものと、積み上がるもの

右側で起きているのは、特別なことではありません。AIが読み書きするフォルダを1つ決めて、そこに素材と手順と過去の成果物を置いているだけです。たとえば提案書を作る仕事なら、デスクトップアプリの画面はこうなります。

提案書 — デスクトップアプリ

エクスプローラー

  • 提案書
  • AGENTS.md使い方
  • 手順
  • 提案書のつくり方.md
  • 素材
  • 会社概要.md
  • 実績一覧.md
  • 過去の提案書
  • 2026-05-A社.md
  • 2026-06-B社.md
  • 出力
  • 2026-08-C社.pdf
提案書のつくり方.md 実績一覧.md

# 提案書のつくり方

 

## 章立て

1. 課題の整理 2. 提案内容 3. 体制 4. 費用

 

## 守ること

- 実績は「素材/実績一覧.md」にあるものだけ書く

- 費用は税抜で書き、内訳を必ず添える

あなたC社向けの提案書を作って

AI手順/提案書のつくり方.md を読みました。素材/実績一覧.md から近い3件を引用し、過去の提案書/2026-06-B社.md の構成に合わせて下書きを作ります。

左のフォルダが前提になる — 説明せずに「作って」で通じる状態

左側がフォルダの中身です。特別なアプリも、専用のシステムも要りません。普通のフォルダにファイルを置いて、それをAIに見せているだけです。ここで重要なのは、いちばん上のAGENTS.md——いくつかのAIツールが共通して最初に読むファイルの慣習で、そのフォルダで何をどう扱うかを書いておく場所です。人間でいえば、新しく入った人に最初に渡す業務マニュアルにあたります。

だから「C社向けの提案書を作って」の一言で通じます。AIは手順を読み、素材を参照し、過去の提案書の書きぶりに合わせて下書きを作ります。前提の説明が、フォルダの中に引っ越したわけです。そして次にやるべきことも分かりやすくなります——回答が気に入らなかったら、プロンプトを工夫するのではなく、手順/提案書のつくり方.mdに1行書き足せばいい。

これはAIに「学習させている」わけではありません。 モデルそのものは1ミリも変わりません。変わるのは、毎回渡している前提のほうです。だからフォルダを整えるほど回答は安定し、フォルダを消せば元どおりになります。逆に言えば、成果はモデルではなくフォルダに貯まるので、乗り換えても持っていけます。

なぜMarkdownなのか — トークンという単位

フォルダに何を置くかで、次に迷うのがファイル形式です。これまで業務文書はWordやExcelで扱ってきましたが、AIに読ませる前提だと相性がよくありません。理由はトークンにあります。

AIは文章をそのまま読むのではなく、トークンという細かい単位に区切って処理します。そして一度に扱えるトークンの量には上限があります。Anthropicは、この性質を有限のattention budget（注意の予算）と表現していて、良い文脈設計とは「望む結果を出すために必要な、情報量の多いトークンの最小集合を見つけること」だと説明しています。つまり渡す情報は多ければ多いほど良い、ではないということです。

Wordファイルの中身は、文章ではなくXML

.docxや.xlsxは、実体としてはZIPで固めたXMLの集まりです。解凍するとword/document.xmlのようなファイルが出てきて、文章はその中に、書式の指定と一緒に埋め込まれています。見出しを1本書くだけで、おおよそ次のような形になります。

Wordの中身見出し1行ぶんの一般的な構造

<w:p>
  <w:pPr><w:pStyle w:val="Heading2"/><w:spacing w:after="321"/></w:pPr>
  <w:r>
    <w:rPr><w:rFonts w:ascii="Yu Gothic"/><w:sz w:val="48"/><w:b/></w:rPr>
    <w:t>第2四半期の実績</w:t>
  </w:r>
</w:p>

Markdownの場合同じ見出しと、続く表・本文

## 第2四半期の実績

| 部門 | 売上 | 前年比 |
| --- | ---: | ---: |
| 法人営業 | 1,450 | +21% |
| 個人向け | 910 | +6% |

**法人営業が伸びた**のは大型案件が2件あったため。

Wordの側で意味を持っている文字は「第2四半期の実績」の8文字だけで、残りはすべて見た目の指定です。表になると、セルひとつごとにこの入れ子がもう一段深くなります。Markdownでは、##が見出し、|が表の区切り、**が強調というように、記号がそのまま構造の意味を持ちます。装飾のための記述がほぼゼロなので、同じ内容なら分量は桁違いに小さくなります。

分量が減ると、なぜ品質が上がるのか

「軽いほうが速い」という話ではありません。効いてくるのは次の4点です。

起きること

なぜ結果に効くのか

本題に使える枠が増える

上限が同じなら、書式の指定に食われない分だけ、参考資料や過去の事例を多く渡せる。

拾い落としが減る

長い文脈ほど中身を正確に思い出しにくくなる（context rot）。短く要点だけのほうが取り違えにくい。

位置を指定して直せる

構造がそのまま伝わるので「2つ目の見出しの表の3行目」が通じる。全文の作り直しが要らない。

変更点が見える

テキストなので前回との差分を1行単位で確認できる。どこが変わったか分からないまま受け取らずに済む。

そしてAIの側も、出力をMarkdownで返せばそのままファイルに保存できます。人が体裁を整え直す工程が挟まらないので、受け取った瞬間から次の処理に渡せる状態になります。ここが、次の話につながります。

Markdownを正本に、出口はコードで固める

「WordをやめてMarkdownにしろ」という話ではありません。配布物としてのPDFやWordは今後も必要です。変えるのはどれを正本にするかだけです。編集はMarkdownで行い、配布形式は毎回そこから作り直します。

Markdownの原稿から、変換と点検のコードを経て、PDFやWord、スライド、Webページ、構成図を作る流れ。修正は常にMarkdown側に戻る
正本はひとつ、出口は用途ごと — 修正は必ず原稿側へ戻す

真ん中にあるのがコードです。といっても大掛かりなものではなく、PythonやTypeScript、環境によってはPowerShellで書いた短い処理の集まりです。担当させるのは主に2つ。ひとつは変換——Markdownからスライドを組む、図の下書きから構成図のSVGを書き出す、PDFに落とす。もうひとつは点検——文字数が枠を超えていないか、リンクが切れていないか、必須の項目が抜けていないかを機械が確かめる。

この2つを人からコードに移した瞬間、出力の性質が変わります。AIの文章はどうしても揺れますが、体裁と検査が毎回まったく同じ手続きで走るので、成果物としての品質は一定の範囲に収まります。「AIの出力はランダムで使いものにならない」と言われる状況の多くは、実は毎回人が体裁を整え直していることが原因です。

図についても同じことが言えます。構成図やフロー図は、画像として貼ると直せなくなりますが、draw.ioの.drawioファイルのようにテキストで持っておけば、AIが直接編集できて、書き出しはコードに任せられます。この記事に載せている構成図も、すべてそうやって作っています。

手順を「スキル」にして持ち運ぶ

手順書とコードがフォルダに揃ってくると、それはスキルと呼ばれる単位になります。2025年12月にAnthropicが公開し、その後オープンな標準仕様として整備されたAgent Skillsは、拍子抜けするほど素朴な形をしています。ただのフォルダです。実際に「提案書のつくり方」というスキルを作るとこうなります。

提案書のつくり方
scripts
references
assets

提案書のつくり方 / SKILL.md

# 名前と説明。AI はまずこの 2 行だけを読む --- name: 提案書のつくり方 description: 提案書の下書きを作る。章立て・書式・ 禁止事項をこのファイルに集約する --- ## 章立て 1. 課題の整理 2. 提案内容 3. 体制 4. 費用 ## 守ること - 実績は references にあるものだけ書く - 費用は税抜で書き、内訳を必ず添える ## 仕上げ scripts/check-required.py で抜けを検査してから scripts/md-to-pdf.py で PDF にする

提案書のつくり方 / scripts / md-to-pdf.py

# Markdown を、社内書式の PDF に変換する from pathlib import Path import subprocess def build(src: Path, out: Path) -> None: subprocess.run([ "pandoc", str(src), "--template", "assets/proposal.latex", "-o", str(out), ], check=True)

提案書のつくり方 / scripts / check-required.py

# 出す前に、必須の章が抜けていないか機械で見る REQUIRED = ["課題の整理", "提案内容", "体制", "費用"] def missing(text: str) -> list[str]: return [r for r in REQUIRED if f"## {r}" not in text] # 抜けがあれば名前を返す。空なら出してよい

提案書のつくり方 / references / 費用の書き方.md

# 費用の書き方 - 金額は税抜で書き、末尾に「（税抜）」を付ける - 内訳は「人日 × 単価」の形まで必ず分解する - 概算のときは「概算」と明記し、前提条件を添える 毎回聞かれることを、ここに1回だけ書いておく

提案書のつくり方 / assets / 提案書テンプレート.md

# ＜顧客名＞様 ご提案書 ## 1. 課題の整理 ## 2. 提案内容 ## 3. 体制と進め方 ## 4. 費用 空の骨組み。AI はここを埋める形で書き始める

ファイル名をクリックすると中身が見られます。フォルダは開閉できます。

中身を見ると、ここまでの話がひとつに収まっているのが分かると思います。SKILL.mdが手順書、scriptsが前章で話した変換と点検のコード、referencesが「毎回聞かれること」の置き場、assetsがひな形。業務のやり方が、フォルダ1つに畳まれた状態です。これを渡せば、渡された側は同じ品質の提案書を作れます。

仕組み側で工夫されているのは読み込み方です。AIは起動時に各スキルの名前と説明だけを読み、いま頼まれた作業に関係しそうだと判断したときに初めて本文を読み込みます（progressive disclosure）。だからスキルを何十本持っていても、普段の文脈を圧迫しません。ここでもトークンの話が効いています。

そしてこの形式は特定のAIに縛られません。Claude Code、Codex、Cursor、GitHub Copilot、VS Code、Gemini CLIなど多くのツールが同じ形式を読めるので、一度書いた手順書はツールを乗り換えても持っていけます。モデルの勢力図は数か月で変わりますが、スキルはそれとは別の時間軸で積み上がっていきます。

zipで配るか、リポジトリに置くか

スキルができたら、次は共有です。ここは規模で答えが変わります。2〜3人で、更新も月に1回程度なら、フォルダをzipで固めて渡すやり方で十分回ります。仕組みを増やすほうがかえって重い。

使う人数と更新頻度の2軸マトリクス。少人数かつ低頻度ならzipで十分、人数か頻度が上がるとリポジトリへ移す
人数と更新頻度で決まる — zipで足りる範囲と、足りなくなる範囲

問題は、うまくいったスキルほど使う人が増え、更新頻度が上がることです。次のような症状が出はじめたら、zipの限界だと考えてよいと思います。

こういう状態になったら

実際に起きていること

「最新版どれですか」と聞かれる

配布のたびに版が枝分かれし、全員が違うものを使っている。

各自が少しずつ手を入れている

改善は起きているのに、それを集めて1本に戻す方法がない。

直したら前より悪くなった

どこを変えたか分からず、元に戻す手段もない。

新しく入った人に渡し忘れる

配布が担当者の記憶に依存していて、抜けても気づけない。

この4つは、ソフトウェア開発が20年以上かけて解いてきた問題そのものです。答えとして定着したのがGitとGitHubで、誰がどこを変えたかが1行単位で残り、レビューしてから取り込め、いつでも前の状態に戻せる。扱う対象がプログラムである必要はありません。手順書もひな形もスクリプトもテキストなので、まったく同じ仕組みに乗ります。

ここが、非エンジニアの業務にGitHubを持ち込む理由です。流行っているからでも、かっこいいからでもなく、更新され続けるものを複数人で共有する手段として、いまのところこれが一番枯れているからです。

置く前に、置いてよいものかを分ける。 手順書には顧客名や単価が紛れ込みがちです。社内で使うならprivateリポジトリにするのは当然として、パスワードやAPIキーは仕組みが違うので絶対に入れない、顧客固有の情報は素材フォルダ側に置いて共有範囲を分ける、といった線引きは最初に決めておくほうが安全です。

実際にやってみた — 弊社の場合

いま読んでいるこの技術ブログも、同じ形で運用しています。リポジトリには記事・スライド・HTMLページの原稿に加えて、それぞれの作り方をスキルとして置いてあります。「HTMLページを作って」と頼めば、AIはページ設計の方針、配色のルール、画像の置き場所、検証の手順までを読んでから書き始めます。

運用の正本はAGENTS.mdという1つのファイルで、ディレクトリ構成・ビルド手順・公開のルールをそこにまとめています。スキルの本体は1か所だけに置き、そこからClaude Code用とCodex用の設定を生成しているので、2つのツールに同じ手順書が配られる状態を保てます。片方だけ直して食い違う、という事故が起きません。

点検もコードに任せています。bun run ciと打つと、原稿のメタ情報の検査、サイト全体のビルド、型検査、そしてスライドの文字が枠からはみ出していないかの自動判定までが一続きで走ります。人間が目視するのは、挿絵を入れたページなど機械が判断しにくいところだけです。

このページ自体も、同じ流れで作りました。設計方針はスキルに書いてあり、構成図は.drawioファイルから書き出し、公開前の検査はコマンド1本です。原稿を書いた人間がやったのは、何をどの順で伝えるかを決めることと、出てきたものを読んで直すことでした。

誰が作り、どこから始めるか

ここまでの話には前提があります。この形は、非エンジニアだけでは立ち上がりません。かといって、エンジニアだけでも作れません。

業務側が持っているもの

エンジニア側が持っているもの

判断の理由、例外の扱い、明文化されていないルール、どこで失敗しやすいか。これは中にいる人しか書けない

手順を分解して書く技術、点検を自動化する技術、共有と巻き戻しの仕組み。これは経験がないと組めない

手順書そのものはただのテキストなので、業務を知っている人が書いたほうが良いものになります。ただ、それを毎回同じ品質で動かすには、要件を聞き取って構造に落とし、変換と点検をコードにし、リポジトリを整える役割が要ります。エンジニアが業務を理解しに行き、業務側の人がフォルダを触りに来る。その中間地点にあるのがリポジトリで、そこを一緒に育てていくという形になります。

最初の一歩は、思っているより小さくて構いません。

  1. デスクトップアプリを入れて、いつものチャットではなく作業させる側（WorkやCodex、Claude Code）で開いてみる
  2. 繰り返している業務を1つ選び、フォルダを1つ作って、素材と過去の成果物を入れる
  3. その仕事のやり方を、箇条書きのMarkdownで1本だけ書く（完璧でなくてよい）
  4. 2人目に同じフォルダを渡して、同じ品質のものが出るか試す
  5. 更新が重なり始めたら、リポジトリへ移す

AIがもっと賢くなるのを待つ必要はありません。同じモデルでも、渡す前提が揃っているかどうかで結果は変わります。ブラウザの中だけで使っているうちは、成果は会話と一緒に消えていきます。フォルダを1つ作った時点から、それは会社に残るものになります。

一次情報・関連資料

製品の構成・提供プラン・対応ツールは変動します。記述は2026年8月9日時点のものです。