原稿を書く水曜日

作業記録の共有メルマガ+原稿3(1300文字) note+tiny習慣ブックカタリスト+読書メモ作り TH+第五章の読み返しうちあわせCast確認→お休み各種日課サブ執筆 8:00 おはようございます。本日はもろもろの原稿作業です。 Textbox: さて、画像を共有したいのですが、どうしましょうかね。 Knowledge Walkers用のimageフォルダにアップロードしてそのURLを使うことにしました。そもそもimgタグがアップロード時に消失していますね。それが問題だったのかもしれません。hugoの変換で消されているのかも。とりあえずテストとして、Textboxにフロントマターのtypeで絞り込めるボタンを付けました。これまでは、検索ボックスにフォーカスしたらプルダウンで一覧メニューが出てくる形ですが、そのデータを利用してボタン化したものです。これで特定のグループを一覧させることが容易くなったと思います。あとは、カード一覧形式以外の表示、具体的にはタイムライン（あるいはCosenseのstream）のように縦に一列に表示させる形です。 9:00 メルマガ: あと、1000字ほど残りがあるので、どうするのか考えましょう。＊　＊　＊ 1300文字ほどの原稿を書きました。これで本編はOKです。ブックカタリスト: アガサ・クリスティーのリスト - BCBookReadingCircle 読書会で話題が上がっていたのでページを作りました。 10:00 note: 記事を書きましょう。＊　＊　＊ publish:ちょっとした工夫で良いんです｜倉下忠憲 11:00 Textbox: Lifelog的なものをどう扱うかずっと考えていました。方策は三つです。現状のnotes/に入れた状態にして、type:lifelogをつける。その際、lifelog/レシピ、のように記述にサブタイプを含められるようにし、それによって親だけ、子だけの集合を作れるようにする。これが一つ目。次に、lifelog/というフォルダーを作り、そこに集める。その際は、type:lifelogは不要になる（フォルダが名前空間を担保しているから）。代わりに、type:レシピ、などを与える。現状はそれがボタンとなって上部にならび、切り分けができる。これが二つ目。最後に、一つ上にlifelog/をつくる。これはbooks/やclips/などと同じレベルであり、一つのアプリの単位と同じ。つまりTextboxの兄弟項目としてつくる。こうすると、既存のtextboxの仕組みはすべて使えなくなるかわりに、まったく新しいindex.htmlをデザインできる。つまりノートツールのUI経験ではなくライフログ用ツールを新しくデザインできる。この三つのうちどの方策を採用するのかを考えていました。で、それぞれには当然一長一短あるわけですが、ポイントは私がライフログ的なものをどこまで「特別なもの」として扱いたいのか、というニーズです。さほど特別でないならば、notes/に入れて他のノートと混ぜておけばよいでしょう。これは、ほぼ日手帳に予定と日記を混ぜて書くのに似ています。一方でものすごく特別なら新しいアプリ単位でlifelog/を作り、専用のindex.htmlを設計します。これはアナログでは「アルバム」を新しく買ってくるようなものです。その中間が、textbox/lifelog/を創るというもの。どれが正解というのはないですし、ある部分で効率化されれば別の部分で非効率になるというトレードオフは必ず存在しています。だから、「効率的かどうか」で考えているのでは判断がつきません。自分のニーズはどういうところにあるのかを見極める必要があります。＊　＊　＊ Evernoteの頃から「一ヶ所に何でも集める」が基本的な方針で、単に利便性以上にいろいろなものが一つのスペースに並んでいる雑多さが気に入っていたように思う。それ以降のツールにおいても、同様の使い方をしてきた。一方でそれは、一つのツールに多機能を求めるか、個別の情報の扱いをややおざなりにすることのどちらかになっていたようにも思う。Evernoteなんてまさにそうだろうし、Obsidianでもやはり限界がある。こういうのを「コンビニ的」とひとまずは呼ぼう。私はコンビニ的なものが好きで、それをこれまでも使ってきた。現状のTextboxはまさにコンビニ的になっているし、しかも「多機能型コンビニ」になりつつある。この状況をどう考えるのか。＊　＊　＊めちゃくちゃ考えましたが、とりあえずTextboxと同じ階層にlifelog/を作ることにしました。それでlifelog専用のindex.htmlを作り、閲覧や新規作成ができるようにします。その上で、そのフォルダの中身をTextboxでも一覧できるようにすればハイブリッド体制になる、というのが私の思惑です。でもって、そういう兄弟フォルダをたくさんつくっても、中身がmdファイルであるならばすべて同じ機構に載せられます。個別的でありながら、統一も可能。そういう状態をまず目指してみます。

September 22, 2026

ニュースレターを書く火曜日

作業記録の共有メルマガ+原稿2(4000文字) ニュースレター+情報の四タイプブックカタリスト+読書メモづくり各種日課サブ執筆 8:00 おはようございます。昨日は少しTextboxのパージ作業を進めました。とりあえず、books.mdとしていたものを、books/フォルダーを作り、index.htmlを設定して、ブックデータベースとやりとりできるようにしました。この感じで進めましょう。ニュースレター: まずはニュースレターから。＊　＊　＊ publish:パーソナルノートの四タイプ - by 倉下忠憲@rashita2 - Rashita’s Newsletter 書きました。 9:00 Textbox: 雑多なノートを書くためのツールをTextboxとは別に考えます。＊　＊　＊ある程度はできました。Gyazoが死んでいるのでスクリーンショットの共有がとても面倒です。＊　＊　＊ Scroll Notes - 倉下忠憲の発想工房いったんCosenseに貼り、そこから画像のURLを取得するテスト。＊　＊　＊なぜかimgタグが表示されませんね。＊　＊　＊＊　＊　＊ CosenseにアップしたURLではうまく解決されない模様。ということは、ローカルのスクリーンショットをサーバーにアップロードするプログラムが必要ですね。一応Knowledge Walkers用であれば簡単にできるはずですが。 13:00 メルマガ: 二つ目の原稿を書きます。＊　＊　＊ 4000文字の原稿を書きました。 16:00 ブックカタリスト: 読書メモをつくります。＊　＊　＊ブックカタリストBC149用メモ - 倉下忠憲の発想工房

September 21, 2026

準備を進める月曜日

作業記録の共有メルマガ+ツイートメルマガ+ファイル準備メルマガ+原稿1(5900文字) 次の企画案+メールを読むブックカタリスト+読書メモづくりブックカタリスト+配信予約作業 textbox+小さいindex.htmlをつくる各種日課集中的読書復文勉強サブ執筆 KW+ミニエッセイ 7:00 おはようございます。本日はもろもろの準備です。Textboxの位置づけについても考えます。 publish:ルーマンの手法：その４ / ソウトラインからの学び / 映画館と余韻時間｜倉下忠憲メルマガ: まずはファイルの準備だけ。＊　＊　＊今週書くことも簡単に決めておきました。 Textbox: プロジェクトを扱うローカルのindex.html（PMH）がいい感じに整ってきたので、Textboxとの統合を検討します。完全に統合するというのではなくて、それぞれの役割を見直す、という方向です。論点はいろいろあるのですが、とりあえず、カレンダー的情報を保存しているtodo-board.mdを独立したhtmlにするのがいいのではないか、というのが第一の案です。そうすると、それに関連して、org的なものはhtmlにして、一つのグループを作るというイメージが湧いてきます。それはつまり、いわゆる手帳的なものはTextboxから切り離し、ノート的なものだけをTextboxに残す、というコンセプトにつながっていきます。＊　＊　＊もう一つの論点は、現状のTextboxが二種の混合になっている点に関してです。ページそのものにJavaScriptを書き、本文は直接に記述せずに、jsonデータからカード一覧などを作るたのページと、純粋なmdファイルでテキストを管理するページの二種類が一つのツール上で混在しています。その雑多さを喜んでいたのですが、混乱も生じますし、それ以上にTextboxというツールの設計がかなり複雑になっています。これは長期的な管理においてはあまりよくないかもしれません。以前、canvasを開くだけのツールや、小さなアウトライナーを作ったときでも、機能の分散化を検討していましたが、現状のTextboxはいろいろできすぎます。これを整理したほうがいいのではないか、という感触があります。 JavaScriptを持ったページは、ようはミニチュアア版のHTMLツールであり、それを気楽に作れるのがTextboxの良さであり、それがHyperCardとの類似点でもあったわけですが、現状のhtmlファイルが生成AIによって気楽に作れるようになっているので、Textboxの優位性そのものが薄れてしまっているかもしれません。できることを増やすことが、長期的に嬉しいとは限らない、というのの例ですね。＊　＊　＊ books.mdというページも、ビュアーとしてしか機能していません。これを別枠に移動させる手はあります。ということは、レイヤーの考え方です。現状はTextboxを開いたら、mdファイルの一覧が並んでいます。そこにはビュアーとしてのmdとページそのもののmdがあります。その二つは基本的に別系統のことをやっています。これが、Obsidianのbasesであれば、階層は違っても系統は同じです。なぜならbasesで作成されるリストは、ページそのもののmdへのリンクだからです。一方で、現状のTextboxのビュアーは、mdファイルの実態とは関係ない、jsonのデータであり、相互に「交流」していません。単に、一つの画面に一緒に並んでいるだけです。そこでまず統一を考えます。たとえば、Textboxのトップ画面では、ビュアーとしてのページだけが並ぶようにする。具体的で個別のページはそこでは表示されない。そして、そのうちの一つ（たとえばorg.md）を選択したら、org.jsonの中身がカード一覧として表示される。ようはTextboxのトップが、より個別的なツールの入り口になっている格好です。＊　＊　＊逆の方策もあるでしょう。ビュアーとしてのページは、mdではなくhtmlファイルにしてしまい、Textboxのトップからは完全に追い出してしまう。で、aタグでそうしたhtmlページへのリンクを置いておく。つまりナビゲーションのレイヤーに追いやる、という形です。こうすると、Textboxは純粋に本文を持つmdファイルを編集するためのツールになります。＊　＊　＊どちらの場合でも実現されるレイヤーは同一です。ツール群のレイヤー本文だけのレイヤー（mdファイル群やJSON）ようは、今のTextboxがどちらのレイヤーを担当するのか、という話で、前者を選べばTextboxはツールの入り口になり、後者を選べばノートの入り口になります。

September 20, 2026

ゆっくり過ごす日曜日

作業記録の共有ブックカタリスト+読書会ページ更新 rashita.net+FPT機能週報作成来週のSTL確認 note+記事を移す 8:00 おはようございます。本日は来週の予定などを確認し、あとはゆっくりします。 rashita.net: これまでは、ロリポップのFTPを使っていたのですが、さすがに面倒ということもあり、自前でFTP体制を整えました。 audible: 五ヶ月間99円とか、何かそういう金額だったので契約しました。＊　＊　＊ 4か月/月額99円で、五ヶ月目から通常価格、という感じでした。 12月の料金までが99円、と理解しておきましょう。 9:00 ブックカタリスト: 読書会ページを更新します。＊　＊　＊ 2026年10月読書会レジュメ - BCBookReadingCircle ついでに自分のページも更新しました。 2026年10月読書会メモ（倉下） - BCBookReadingCircle 週報作成: まずは一週間の振り返りから。＊　＊　＊そういえば、Gyazoがメンテで使えないので、画像をはるのが結構面倒ですね。 FTPの仕組みが作れたのならば、画像をレンタルサーバーにアップしてURLを返すGyazoっぽい仕組みを作ってもいいかもしれません。AmazonのS3とかの手もありますが。＊　＊　＊第37週の振り返りを作成しました。現状、Textboxにもそのノートを置き、同じファイルを別のフォルダにもコピーしています。この辺をうまく調整したいですね。あるいは、原本とコピーというような理解の仕方でもいいのかもしれませんが。来週のSTL確認: まずはスケジュールから。＊　＊　＊来週は見事に予定がありませんね。原稿に集中しましょう。＊　＊　＊でもって、来週のタスクとリスト。すでにこの構図が崩れかかっている気もします。ひとまず各種プロジェクトのtodoをピックアップするページは作りました。それをざっと目を通していく形がよいでしょうか。＊　＊　＊ todo.htmlページで一覧し、修正が必要なものはそこから各todo.txtを開いて、という感じでいきましょう。編集したら、python3 scripts/build_todo.py を実行すればtodo.htmlがアップデートされます。＊　＊　＊最後にlist。これがやっかいですね。現状はTextboxで、list.jsonの中身をカード型で表示しています。で、月替わりの作業をするときはここに「月替わり作業のリスト」があるのでそこからコピペして使う、という段取りがありますが、基本的に動いているのはそのリストだけ。他にも雑多なリストがありますが、稼働率は低いです。その上で、orgの情報がindex.html化していることを考えると、こうした情報もhtml化することは考えられます。引いては、これはTextboxとorgとの使い分けを考えることにもつながるでしょう。ひとまず、その問題意識だけ書き残して次にいきましょう。 10:00 note: 記事を移します。

September 19, 2026

メルマガを仕上げる土曜日

作業記録の共有 getbookFeed+コードの修正ツイート振り返りメルマガ+はじめにメルマガ+全体稿確認メルマガ+配信予約 note+記事を移す note+デジタル・クラフト rashita.net+ビルド体制を整える図書館返却各種日課サブ執筆 20:00~ 読書会 7:00 おはようございます。本日はメルマガを仕上げます。あと、夜からは読書会です。 rashita.netのビルド体制も整えたいですね。と、名前がややこしくなってきました。rashita.net/blog　が R-styleだったので、上位をなんと呼ぶべきかまだあやふやです。 getbookFeed: なぜかISBNで電撃文庫の書誌情報をAmazonのAPIから叩けなくなっていたので、処理を切り分けました。まずISBNでダイレクトに探し、それで見つからなければISBNで検索する、というルートです。 8:00 ツイート振り返り: まずは一週間分のツイートの振り返りから。＊　＊　＊ OKです。 9:00 メルマガ: 「はじめに」を書きます。＊　＊　＊書けました。 10:00 メルマガ: 全体稿を読み返します。＊　＊　＊読み返しが終わりました。配信予約作業にうつりましょう。＊　＊　＊まぐまぐOKです。＊　＊　＊ noteもOKです。これで今週のメルマガ作業は一段落しました。 noteを見ていて、先週ニュースレターからnoteに記事を移すのを忘れていますね。今日中にやっておきましょう。 note: ニュースレターから記事を移します。＊　＊　＊ OKです。明日も移しましょう。アイデアと距離を置いてからの処理｜倉下忠憲＊　＊　＊ publish:デジタル・クラフト（と呼んでいる）｜倉下忠憲勢いで記事も書きました。

September 18, 2026

企画案を進める金曜日

作業記録の共有ニュースレター+小さなツールづくり org+todoボードづくり org+継続的プロジェクトの扱い org+rashita.netの扱い次の企画案+メール作成ブックカタリスト+読書メモ作り各種日課サブ執筆 8:00 おはようございます。本日はニュースレターと次の企画案周りの作業です。 org: index.htmlをリデザインします。＊　＊　＊最初は上部をつめていきなりプロジェクトカードが並ぶようにしたのですが、それだとかなり息が詰まるということがわかり、Notionのように画像を入れることにしました。そういえば、Evernoteもこんな感じにできますね。その上で、todoを一覧するtodo.htmlをつくりました。 index.htmlがプロジェクトを一覧するものなら、こちらはtodoを一覧するものです。本当はカード型にしてタイル上に並べる形を想定していましたが、astraが最初に出してきたこのスタイルを採用してみることにしました。使いながら調整していきましょう。＊　＊　＊明日、gptが一週間のリセットなんですが、あと44%も残っていますね。htmlを管理させるくらいならぜんぜん使わないイメージです。まあ、このレベルの作業ならもっと下のモデルでも十分なんですけども。 9:00 ニュースレター: メンバー限定記事を書きましょう。＊　＊　＊小さな道具をたくさんつくる | メンバー限定記事 - by 倉下忠憲@rashita2 書けました。 13:00 org: 単独のプロジェクトはindex.htmlが作れました。次に、継続的プロジェクトについて考えます。メルマガやR-styleやニュースレターなど。＊　＊　＊継続的プロジェクトは、書籍執筆プロジェクトとは必要なファイル構造が違ってきます。増えていくテキストや更新の手順、必要なURLなどの情報が必要です。「ネタ帳」という概念が出てくるのもこうしたプロジェクトだけです。＊　＊　＊ R-style blog、あるいはそれよりも上のWebサイトにおいても「記事を書くためのインターフェース」があってもいいです。ローカルサーバを立ち上げれば、index.htmlからmdファイルを生成できますし、そうでなくてもマークダウンファイルの新規作成は可能でしょう。フロントマターの記述が必要になるなら、それも補佐できるはずです。＊　＊　＊一つのページにすべての情報を詰め込むのではなく、むしろリンクを活かして、それぞれのページが「自分の得意なことをやる」という感じでいきます。＊　＊　＊ R-style/のフォルダが扱いが難しいですね。今はそれよりも上のルートでの作業をしているので、ローカルのファイル設定も考え直しが必要です。 13:00 次の企画案: メールを返信しましょう。＊　＊　＊勢いでメールを書きました。 15:00 org: rashita.

September 17, 2026

うちあわせCastな木曜日

作業記録の共有メルマガ+原稿1（5000文字）図書館返却メルマガ+原稿2(2000字) メルマガ+原稿3(4000文字) 次の企画案+メール返信読了ツイート 14:00~うちあわせCast収録各種日課集中的読書復文勉強サブ執筆 KW+ミニエッセイ 7:00 おはようございます。本日は午後からうちあわせCastです。午前中は原稿を進めましょう。 Web読み: いくつか記事を読みました。 2026/9 - 倉下忠憲の発想工房 8:00 メルマガ: まずは原稿を書きましょう。＊　＊　＊ 5000字の原稿を書きました。 11:00 図書館に行ってきました。メルマガ: 二つ目の原稿を書きます。＊　＊　＊ 2000字の原稿を書きました。 14:00 うちあわせCast: 収録です。＊　＊　＊終わりました。 publish:第百九十七回：Tak.さんとテスト駆動式執筆作成者：うちあわせCast 16:00 メルマガ: 原稿を書きましょう。＊　＊　＊ 4000字の原稿を書きました。これで本編はOKです。 17:00 KW: 今日のエッセイを書きましょう。＊　＊　＊今日のエッセイ | Knowledge Walkers

September 16, 2026

健康診断な水曜日

作業記録の共有テキストコンパイラ健康診断ブックカタリスト+アフターブックカタリスト+読書メモ準備メルマガ+原稿1 TH+アウトラインファイルの整理各種日課集中的読書復文勉強サブ執筆 KW+ミニエッセイ Textbox+paddingを増やす 7:00 おはようございます。本日は朝から健康診断です。ご飯はそれまでお預け。ひとまず、病院にいくまでは原稿を書きましょう。テキストコンパイラ: 現状THでは、Drafts/の中に章ごとにファイルが分かれて保存されています。これはこれで扱いが便利なのですが、通して読みたい、といった要望に応えられません。これをなんとかしようと思います。＊　＊　＊まずは、複数のテキストファイルからまとまったテキストファイルを作成するコードをつくりました。それだけでも結構決めることがあります。その上で、そのファイルから他の形式に移せればGoodです。＊　＊　＊長い原稿の取り回し問題: これはもうメルマガで書いたほうがよい気がしてきましたが、ようは自分が何を欲しているのかを考える必要があります。複数の原稿ファイルがあるとして、じゃあ「全体」はどのように必要なのか。全体を通して読めることなのか、前後の章のつながりを確認できることなのか、今何がどこまで書けているのかを確認できることなのか、自分が今書いた章が、全体の中でどう位置づけられているのかを確認することなのか。この辺の力点を見極めたいです。 8:00 Textbox: デザインはかなりCosenseによせているはずなのに、どうも窮屈な感じがするなと感じていたのですが、もしかしたpaddingが足りていないのでは、と思い至りました。これを拡げます。＊　＊　＊だいぶ余裕が出てきました。もうちょっと拡げてもよいかもしれませんね。余白、大切です。 10:00 健康診断が終わりました。朝から何も食べていないのでいったん食事です。章ごとにファイルを分ける: https://x.com/rashita2/status/2099833106433978663 気になったのでツイートしてみたら、存外に「一つのファイルにまとめる」人が多かったです。Wordなどを使う場合は自然とそうなるわけですが、ちょっと以外でした。自分の環境でもそのイメージを検討してみてもいいのかもしれません。内部的にはmdファイルがまとまっている、という形も当然ありでしょう。ただ、アプリケーション上は一つのファイルとして扱える、という形です。Scrivenerはそうなっています。 11:00 ブックカタリスト: アフターの下書きを進めましょう。＊　＊　＊書きました。ついでに読書メモの書誌情報を整理しておきます。＊　＊　＊ブックカタリストBC149用メモ - 倉下忠憲の発想工房 OKです。 14:00 章ごとにファイルを分けない: ビルド方式で統合ファイルができたので、それを開いたときの感じを確かめます。

September 15, 2026

ブックカタリストな火曜日

作業記録の共有ニュースレター+頭を使うこと TH+第四章最終チェック TH+第四章共有メルマガ+原稿1 13:30~ ブックカタリスト収録各種日課集中的読書復文勉強サブ執筆 KW+ミニエッセイ 8:00 おはようございます。本日は午後からブックカタリストです。午前中は各種原稿を進めましょう。ニュースレター: まずはニュースレターから。＊　＊　＊ publish:「頭を使わなくていいんです」というメッセージ - by 倉下忠憲@rashita2 書けました。 10:00 TH: 第四章を読み返します。＊　＊　＊原稿を読み返すときに、行頭を見たら奇妙なことに気がつきました。 Obsidianで管理していたときの名残でフロントマターがついているのですが、そもそもどれも不要になっています。 word-countはエージェントにファイルをチェックしてもらえばいいですし、orderはファイル名で管理できます。その上、typeは、原稿用のフォルダに入って要るのだから当然のことを書いています。これ、全部いらないですね。唯一、付け加えるとしたら、state: で原稿の状態を管理するくらいです。となると、もうYAMLである必要も感じません。そこで、コメント形式を採用することにしました。コメント・プロパティ - 倉下忠憲の発想工房これで十分です。プロジェクトにおけるファイルの管理と、いわゆるナレッジをファイルで扱うことには、基本的な手つきの差がありそうです。＊　＊　＊ BextEditorのハイライトがコメント記法に対応していなかったので、Astraに書いてもらいました。一瞬でした。これで十分でしょう。これなら一行目に置く必要すらありません（いちおう置きますが）。＊　＊　＊全体を読み直し、Googleドキュメントに貼り付けた上で、もう一度読み直して手を入れて、編集者さんに共有しました。これで第四章は終わりにして、第五章に取り掛かります。で、です。これをindex.htmlに反映する必要があります。で、それはある種gitのpushに近い営みだと言えるでしょう。 13:00 ブックカタリスト: 収録します。＊　＊　＊

September 14, 2026

準備を進める月曜日

作業記録の共有メルマガ+ツイートメルマガ+ファイル準備タスク整理+次のアクションを整理するタスク整理+次のアクションを整理するノートツールのデザインアウトライナー作り+Astraで作成 TH+第四章(sec07,08) 各種日課集中的読書復文勉強サブ執筆 KW+ミニエッセイ 7:00 おはようございます。本日はもろもろの準備デーです。あと、映画を観に行く予定です。 publish:ルーマンの手法：その３ / 生成AIと記事を書く｜倉下忠憲メルマガ: まずはファイルの準備から。＊　＊　＊ OKです。今週書くこともざっと決めておきました。タスク整理: たとえば今、WorkFlowyに「Next Actions」という項目があり、そこにやることを集めています。これはこれで便利なのですが、Project Hubと別の場所、別の形になっています。これをどう考えるのか。あと、そもそも使っているときと、そうでないときがあります。ここが大きな問題なのかもしれません。todayの項目の横に表示させることはできますが、だからといって何？という感じです。個別の独立した作業（プロジェクトにひもつかない作業）はデイリーの中にいれ、todoをつけることにします。では、プロジェクトに紐付いたものは？プロジェクトのメモファイルに想いを書き、そこからタスクとして起こしたものをここに書く、という運用は十分ありえますが、現状そこまで滑らかとも言えません。WorkFLowyに書いておくと、mcpがあるのでエージェントからの運用が楽という点はあって、そこは評価できます。どのフォルダで作業していても「作業リスト置き場」として機能してくれます。参照だけでなく保存もできる。つまり？実作業そのものはフォルダ内で行い、情報もフォルダに入れる。しかし「やること」に関する情報は、WorkFlowyで扱うようにする。こういう二段構えもありでしょう。「やること/やったこと」は、リファレンスでもドラフトでもないわけで、それを未来永劫保存しておかなくてもよいわけですから。あるいは、「やること」もフォルダ内で扱い、それをindex.htmlと共に統合する（agenda）という手法もあります。org方式です。＊　＊　＊毎日は、フォルダ内で作業すればよく、一週間に一度「さて、自分がやることはなんだったけな？」と考える。そのときに、agendaを作ればいいのではないか？agendaを「維持」しようとするからおかしくなるのではないか？＊　＊　＊ GTDはコンテキスト別のリストを作ることを提案した。しかし、パソコンで作業している、ホームワーカーにとって作業のコンテキストはあまり意味を持たない。プロジェクト、午前・午後、体の疲れ、のようなコンテキストが別途必用となる。タスクの情報を一ヶ所に集め、それぞれにメタ情報を付与しておけば、そのようなコンテキスト別のフィルターも作成はできる。悪くはない。いや、プロジェクトの情報からタスクリストを作る、ということをエージェントにやらせるならば、実はそれがプロジェクト内であろうが外であろうがあまり関係がない。人間が作業するならば、たとえばプロジェクト用のフォルダで作業しているのに、保存先をフォルダ外にするのは認知的に手間だ。だから内側に保存しておきたい。一方でそうなると総合的な視点がなくなる。エージェントであれば、そのような認知的手間はない。だとしたら、別にどちらであってもいい。ようは「次にやることリスト」がいつどのような場面で要請されるのか、ということ。＊　＊　＊「よし、今日やることを決めるぞ！」というタイミングで使われてきたことはほぼない。むしろ、ちょっと手が空いたタイミングで何かあったっけ、という感じで使っている。もうそのときには今日のやることリストはできている。＊　＊　＊あまり使われないNext Actionリストは、自分の意志が反映されていない。過去のスナップショットに過ぎない。これではあまり意味がない。

→ 1