工作清單

【知らなきゃ損】CodexやClaude Codeの力を最大限引き出すAIのフォルダ設計を教えます

逐字稿文字預覽

皆さん、こんにちは。AI
プログラミング講師の今にです。
今にさん。
はい。
いや、なんか今にさんが以前AI秘書作と思うんですけど、フォルダーめっちゃ凝ってたじゃないですか。
ま、それなりにね、あの、フォルダー設計が大事なんです。
うーん。ま、そうね。ま、フォルダーの設計は間違いなく
AIエージェントを動かす上では、ま、それこそハーネスに当たるからめっちゃ大事。
ハーネス、AIの周りの環境でしょ。
そう、そう、そう、そう。どうしたらいいんですか?
どうしたらいい?なんか自分でやる時。
ああ、別にね、あの、AI秘書のフォルダーそのまま使うのもいいし、ま、自分でオリジナル作ってもいいし、ま、言っとくけど、あのフォル設計、あの、いわゆるディレクトリー設計みたいなものはあれ正解
1つじゃないからね。
はい。はい。あ、1つじゃない。
そう。正解ってそもそも決まってるわけではなくて、ま、いろんな人がいろんな考えのもを自分自身でこういうフォルダーの設計にしようとかっていうの決めてやってるわけで、そのうちの
1つが、ま、僕がお見せしたあの秘書のやり方なんだよね。
はい。はい。
あれってそもそも正解がないって言うとなんかどういうパターンがあるんすか?うん。ああ、なるほどね。いい質問するじゃん。
お、ま、僕のコーデックスの秘書とかクロドコードの秘が、ま、1つのパターンだし、ま、他にも著名な人たちがこういうフォロード設計でやってるとか、こういう風にしてるとか、ま、そこさっきも言ったハーネスに当たるので、あ、ハーネス知らない人は是非ハーネスエンジリングの動画ご覧いただけたらなと思いますが、ハーネスに当たるのでハーネスの設計みたいな観点でいくと、ま、本当パターンがあるかなって、それちょうどね、説明した動画がありますので、今日は、ま、ちょっと特殊なんですけども、
[音楽]J君なしで、J君なしジ君いらないみたいなコメントたまについてしまうのであれなんですけども僕はいると思うけどねしで僕がひたすら分かりやすく説明した動画すでに撮影しておりますのでそれを皆さんにご覧いただこうかなという風に思ってます。
はい。ということでAI
エージェントに最適なディレクトリーフォルダー設計ということで是非こちらの動画ご覧ください。
同じクロードコードやコデックスを使っているのに、ある人のAIエージェントは必要な資料をすぐに見つけて前に決めたルールを踏まえながら仕事を進めてくれる。一方で自分のAIは毎回[音楽]同じ
説明を求めてきたり、過去の決定を忘れたり、違う資料を参考にしてしまったりする。この差を見るとなんかモデルや
ブロンプとテクニックの違いだと思いやすいです。え、もちろんそれらも重要
です。ただその前に見直して欲しいのが
AIにどのフォルダーを見せているのか、どんな名前のファイルを置いているのか、そして途中経過や成果物をどこへ戻してもらうのかなどです。え、今回の結論一言
で言うとフォルダはファイルの整理棚であると同時にAIに渡す仕事場でもあるということです。例えばですが、人間でも何
も分類されていない倉庫に入れられて、過去の資料参考に提案書を作ってくださいと言われたら困りますよね。どれが参考
資料なのか、どれが最新場なのか、何を基準に判断し完成物をどこへおけばいいのか何も分からないからです。反対に
受け取った資料はここ、判断基準はここ、作業中のものはここ、完成物はここと決まっていれば仕事を進めやすくなります。AIも同じです。今回は目的の異なる5
つのフォルダ構成を実際にどんなフォルダーやファイルが並んでいるのかまで具体的に見ていきます。形をそのまま
コピーしていくのではなく、AIがどこから仕事を始め、何を読み、どこへ成果物を残すのかに注目してください。最初に
抑えておきたいのはフォルダ設計に1つの正解はないということです。仕事の流れが
違えば必要な箱も変わります。え、
ソフトウェア開発なら調査結果や実装計画を残す場所が重要です。資料を集めて知識
を育てるなら、元資料と整理済みの知識を分ける場所が必要になります。AIを秘書
のように使うなら依頼を受け取る場所と成果物を返す[音楽]場所が必要になります。そしてAIはファイル名や
フォルダー名を手がかりに読むものを探します。資料1最終版最終版の修正と並んで
いるより顧客ヒアリング契約書案書納品物と分かれている方が次に何を読むべきか判断しやすいですよね。名前を見れば次に
何を読めば良いかわかる。さらに調査結果
は調査の場所へ。計画は計画の場所へ。
生物は完成物の場所へ残しておけば次のセッションでも続きから始められます。
ポルダ設計は見た目を綺麗にするためではなくAIが探索し、判断し、作業し、引き継ぐための土台です。ここからは各例
の構造を上から順に見た後、ファイルがどのように移動し、どこでAIが判断するのかまで追っていきます。1つ目は
クロードコードの開発者であるボリスチェルニー氏が公開している運用方針を元にした指示を分割する考え方です。ま、
ここはですね、ちょっと誤解が出やすいので最初に区別しておきます。今から説明
するのはボリス氏の非公開ワークスペースをそのまま再現したものではありません。
ボリス氏が公開したスラッシュチェックアップなどで示しているのcloud.MDを熱くしすぎず回の指示書やスキルへ分けるという方針を業務用のま架空の例に置き換えたものです。画面の
構造は大きく三層に分かれています。1番
上にプロジェクト全体で毎回読む薄いcloud.MDがあります。え、その下
にコンテンやファイナンスのような仕事ごとのフォルダーがあり、それぞれの中にその領域だけで守るcloud.MDがあります。さらに.Cloudの中に
スキルズがあり、YouTube台本や請求所確認のように特定の作業でしか使わない詳しい手順を置きます。例えば
YouTubeの台本を作るとします。
最初に読むのcloud.MDにはこのプロジェクトは何のためにあるのか絶対に触ってはいけない場所はどこか成果物をどこへ保存するのかといった全体共通のルールだけを書きます。次にコンテンの中
へ入った時は発信業務だけのcloud.MDを読みます。[音楽]
え、ここには想定視聴者を先に明確にすること。専門用語は、え、初手で説明する
こと。え、事実を捜索しないことといった
発信業務の共通ルールが入ってます。
そして実際に台本を作る時だけYouTubeのskill.MDを読みます。そこには
台本の作成手順、レビュー項目、納品形式など台本作成にしか必要のない詳しい内容を置きます。この時経理用のcloud.
MDや請求所確認用のSK.MDは読む必要がありません。反対に請求書を確認
する時は全体の共通ルールと経理のルール、そして請求所確認の手順だけを使います。発信業務の細かいルールは関係[音楽]
ありません。つまり指示を削っているので
はなく読むタイミングっていうのを分けてるんですね。毎回必要な情報は上に薄く
置いておく。特定の領域で必要な情報は
その領域の中へ置く。詳しい作業手順は
必要な時だけ読むスキルへ置く。失敗から
得た学びを戻す場所も同じ考え方で決められます。どの仕事でも起きる失敗なら
ルートへ足す。え、発信業務だけの失敗
ならコンテン足す。YouTube台本
だけの改善なら台本作成のスキルへ足す。
[音楽]はい、今回の例から持ち替えて欲しいのは全ての指示を1枚へ詰め込まないということです。共通のルール、領域
ごとのルール、作業ごとの手順を分けるとAIが今の仕事に必要な情報だけを使いやすくなります。2つ目はアンドレペシ氏
が公開したLLMwikの考え方です。
こちらが解決するのは資料は増えているのに知識として使える状態にならないという問題です。ま、1番上にMywikという
フォルダーがあります。で、その直化には
ローとwikという2つのフォルダー。
そしてAIがこのwikをどう扱うのかを定めているagent.MDがあります。
王の中にはArticles、Papers、DataImagesといった元資料の種類ごとのフォルダーがあります。記事はアーティクルズへ、論文
はPaperズへ、数値データはデータへ、画像はへ入れます。一方、Wiの中には
最初に読むindex.MD、更新履歴を残すlog.md、そして概念や比較を整理した複数のページがあります。
構造を一言で表すと片方に原本、もう片方に整理済みの知識がある状態です。ま、
例えばですけど、AIエージェントに関する新しい記事を1つ入手したとします。まずその記事をローのアーティクルズへ
保存します。AIは大元のAGEN.MD
を読み元資料は書き換えないことWiの形式出点の残し方index.MDとlog.mmdも更新することを確認します。で、次にWiの中に関連するページ
があるかを探すんですね。[音楽]
関連ページがあれば追求しなければ新しいページを作っていくと比較に使える内容なら比較ページにも反映していく。で、
その後index.mdに新しい入り口を追加し、log...MDにいつどの資料からどのページを更新したのかを残していきます。1つの資料がローへ入り、
Wiキページへ反映され、目次と更新履歴までつがる。これが1回の知識化の流れ
です。はい。この構造ではどこまでが原分
でどこからがAIによる整理ななのかってのが混ざりません。ローは証拠です。ウキ
はその証拠をもに原分を元に作った繰り返し使える知識です。さらに資料が
100個あっても最初から100個全てを読む必要はありません。まずindex
.MDを読み必要なWiキページだけを開けばいいんですよね。そしてAIとの
やり取りでいい比較や整理ができたらその成果を[音楽]へ戻すと。で、次は前回の
成果から始められるみたいな、ま、そんな流れが組めるわけです。元資料を置くロー
、整理した知識を置くWi、入口となるindex.MD、[音楽]更新を残すlog..MD。ま、この役割を分ける
ことで資料の山が少しずつ使える知識に変わっていきます。3つ目はDEX方士C
たちヒューマンレイヤーが公開している開発運用の考え方です。え、この方が解決
するのはAIが前提を十分に理解しないままいきなり[音楽]完成物を作り始めるという問題です。ま、1番上にソーツと
いうフォルダーがあります。その中には
メンバー名ごとの個人領域とチームで共有するシェアドというフォルダーがあります。え、個人領域にはチケットやノーツが
あり、シェアードの中にはリサーチプランズ、PR[音楽]があります。はい。これは、え、今回です
ね、特に重要なのはこのシェアードの3つです。リサーチは[音楽]調査結果を置く
場所。プランズは実行前の計画を置く場所
。PR、え、実際に行った変更や人間に
確認して欲しい内容を置く場所です。ま、
PRズって書いてあるんですけども、プルリクのことだと思いますね。ま、
いわゆる確認の場所ですと。はい。で、
この構成ではいきなり完成物へ進みません。まずAIが今の仕組みはどうなっている
のか、関連するファイルはどこにあるのか、どんな制約があるのか、まだ分からないことは何かを調べます。その結果を
リサーチの中にマークダンファイルとして残します。ファイル名には日付や案件面を
入れ、名前だけでもいつ何のために行った調査なのか分かるようにします。次にその
調査結果をにプランズの中へ実行計画を作ります。どこを変更するのか、どの順番
で進めるのか、各段階で何を確認するのか、何を持って完了とするのか、ここまで書いた段階で人間が確認するわけです。
方向が違っていてもまだ計画なので小さな修正で進みます。[音楽]
問題がなければAIが計画に沿って作業を進めていきます。開発ならソースの中に
コードを作り、資料政策ならデリバラブルズのような成果物フォルダーへ完成物を置いていきます。え、そして何
を変更したのか、どこを確認して欲しいのかをプルリクズへつげていきます。え、ファイルの流れと
してはリサーチからプランズへ進み、人間の確認を挟んで実際の成果物へ進む形です。悪い調査から悪い計画が生まれていき、
悪い計画から大量の悪い物が生まれます。
なので人間の確認を最後だけに置かずリサーチとプランズの段階に置いていくわけです。ま、これは別に開発以外にも
使えるんですよね。例えば研修の企画なら
市場や顧客の情報をリサーチへ残し、対象者やゴール、小性、政策手順をプラン図へ残してから教材を作るとか動画制作ならリサーチ、企画設計台本という順番をファイルとして残してから完成現行へ進ん
でいくと、ま、この例から持ち帰って欲しいのは完成物だけが成果物ではないということです。調査結果も成果物です。
計画も成果物です。
え、途中警戒、置き場所を作ることで、え、人間は早い段階で確認でき、AIも次のセッションで続きを理解しやすくなります。
いさん、はい。
ついに完成したんすね。
そうなんよ。完成しちゃいました。なんとですね、皆さんに有効お見せしていた私の資料作成スキル。これを配布する準備がついに整いました。
ちなみにこのスキルはどうやったらもらえるんですか?
こちらに記載のキーワード。
YouTubeの概要欄にも記載のキーワードをLINE登録後にご入力いただけたら説明そしてそのスキルのファイル類をですね、お送りする形となっております。もう今お見せしているようなこんな感じの資料がですね、作れるようなキル完成しましたのでぜ非ぜひ皆さん
LINEより受け取ったけたら嬉しいなと思います。
4つ目は皆さんご存知かもしれません。
OpenCRですね。一時期めちゃくちゃ有名になったのワークスペースです。
[音楽]これはですね、フォルダーよりも役割の違うマークダンファイルが並んでいるってのが特徴です。これ初めて知った時
僕もね、面白いなと思いました。はい。
1番上にOpenCRという、ま、この上駐型のAIエージェントですね。はい。
このワークスペースがありますと。はい。
で、その直化にSoul.m、Identi.m、User.m、ツs.m、ハート.MDなどがあります。さらに日付
ごとの記録を残すメモリーフォルダーと必要な時だけ使う手順を入れるスキルズフォルダーがあります。初めて見ると結構
多く感じますがそれぞれがまになっている役割、ま

來源：transcript.txt

本次執行流程與問題處理

  1. 下達指令

    指令：videonote https://www.youtube.com/watch?v=0dIW2HVFv3w --language ja --bilingual --learning --auto-source-subtitles

    來源：https://www.youtube.com/watch?v=0dIW2HVFv3w

    辨識語言：ja ｜ 參數：--language ja --bilingual --learning --auto-source-subtitles

  2. 預期流程

    依指令產生的處理順序：

    1. 自動字幕優先，Whisper 作為備援
    2. 來源選擇與品質檢查
    3. 文字校正與句子單元
    4. 雙語翻譯
    5. 雙語時間軸與學習單元
    6. 筆記與發布
    7. 公開網頁發布

  3. 1. 下載與語音辨識

    工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）

    處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿

    產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）

    耗時：3.4 秒

    關係：依序執行

    結果：完成

  4. 2. 全文快速校讀

    工具：videonote_rapid_transcript_review.py

    處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目

    產出：rapid_transcript_review_report.json（產出檔案）

    耗時：64.1 秒

    關係：依序執行

    結果：完成

  5. 3. 建立句子單元

    工具：videonote-build-sentence-units

    處理：將逐字稿切成帶時間軸的句子單元

    產出：sentence_units.json（句子單元）

    耗時：0.2 秒

    關係：依序執行

    結果：完成

  6. 4. 時間軸稽核

    工具：videonote_timeline_audit.py

    處理：檢查時間軸與音訊對齊

    產出：timeline_audit_report.json（時間軸稽核）

    耗時：0.2 秒

    關係：依序執行

    結果：完成

  7. 5. 品質檢查

    工具：videonote_controlled_quality.py（檢查時間軸與品質）

    處理：檢查語言、時間軸與可讀性品質

    產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）

    耗時：0.3 秒

    關係：依序執行

    結果：完成

  8. 6. 播放時間軸回填

    工具：videonote_rebase_display_timeline.py

    處理：將網頁播放時間軸回填為校正字幕時間

    產出：display_timeline_rebase_report.json（時間軸回填報告）

    耗時：0.3 秒

    關係：依序執行

    結果：完成

  9. 7. 雙語翻譯

    工具：vnt-sentence（句子雙語翻譯）

    處理：將句子翻譯成繁體中文

    產出：sentence_bilingual_transcript.json（雙語逐字稿）

    耗時：164.6 秒

    關係：依序執行

    結果：完成

  10. 8. 雙語時間軸與學習單元

    工具：videonote_learning_timeline_v2.py（建立雙語時間軸與學習單元）

    處理：建立雙語時間軸與學習內容

    產出：sentence_bilingual_timeline.html（雙語時間軸頁）、learning.json（學習單元）、japanese_learning.json（日文學習單元）

    耗時：125.0 秒

    關係：依序執行

    結果：完成

  11. 9. 生成筆記摘要

    工具：videonote-generate-note（生成筆記摘要）

    處理：生成筆記摘要與重點

    產出：note.md（筆記 Markdown）、note.html（筆記 HTML）

    耗時：148.5 秒

    關係：依序執行

    結果：完成

  12. 10. 建立筆記頁面

    工具：videonote-render-html（產生筆記 HTML）

    處理：產生可閱讀的筆記 HTML 頁面

    產出：note.html（筆記 HTML）

    耗時：0.6 秒

    關係：依序執行

    結果：完成

  13. 11. 發布公開頁面

    工具：videonote-publish（發布公開頁面）

    處理：發布到公開網站與每日列表

    產出：公開筆記網址、result.json（管線結果）

    耗時：0.7 秒

    關係：依序執行

    結果：完成

手動來源字幕

自動來源字幕

Whisper 字幕

Qwen 字幕

Parakeet 字幕

MOSS 字幕

聲學時間證據（PyAnnote / WhisperX）

校正前後逐字稿

目前待解決問題與初步改善方向

進一步精進字幕與筆記
使用 Workbench 上傳校正字幕、中文參考稿或回饋 SRT，重新產生雙語與學習單元。
開啟 Workbench