Cosenseの不正アクセスとクラウドの危うさ
はい。うちあわせCast第百九十七回ということで、今回もゲストにたくさんお迎えしております。よろしくお願いします。
よろしくお願いします。
ちょっとデカめのニュースなんですけども、画像。
画像。
スクリーンショットとか画像ファイルをクラウドに上げたら、URLが発行されるんで、共有とかに便利ですよということで、
僕がよく使っているCosenseに画像ファイルをアップしたときに、画像に送られる設定をしているんで、結構使っているんですけども、
不正アクセスがあり、ユーザーの情報、IDとかの情報とともに、画像のメタ情報が盗まれた可能性があると。
画像そのものが盗まれたという感じではないんですけど、画像にアクセスするためのURLが多分メタ情報として含まれてますし、
あと一番厄介なのは、OCRをして実行されてるんで、画像に含まれてたテキストも盗み見られた可能性があると。
これはかなり致命的だとは思うんですけども。
そうですね。
画像そのものは盗まれてなくても、URLが分かっていると、ウェブ一般に公開しているつもりじゃなくても、URLがあればアクセスできるのがクラウドなので、
現状、昔の方がアクセスされた可能性のある画像が、例えばCosense上で表示されないようになってます。
あれは意図的に切ってるわけですね。
そのURLが分かってしまうと画像まで見られてしまうんで、とりあえずURLと画像の結びつきを切ってるんやと思います。
実際どうなってるのかはおそらくそういうことだろうと思います。
当然クレジットカードの情報は抜かれてはないというのがあって、そこはいいんですけども、
いくつかの個人情報等々が含まれてた場合、それを盗み見られた可能性があると。
ちょっと前にさくらインターネットというサービスも不正アクセスがあり、僕もさくらインターネットを使ってたので、
メールアドレスを別に変える必要はないけど、心配だったら変えてくださいみたいな連絡が来てたんですけども、
ひとまず言えるのは、脆弱性があれば疲れる可能性があるというか、ほぼ疲れると思った方がいいぐらい簡単に脆弱性が疲れる状況になってきておりまして、
これはもう100%生成偉いのせいというか、生成偉い由来やと僕は思いますけど、
僕のような個人ユースの場合は別にそもそもそんな危険な情報を画像とかに上げることはしてないので、
個人ユースも含めたりしてないので別にいいんですけど、
企業ユースとかの場合、これを結構致命的な事態になったんじゃないかなとはちょっと感じますね。
そうですね。
あとね、昔のエバーノート式にすべてを記憶するみたいな感覚で、いろんなものを上げちゃってたりする。
まあ、画像でそれやる人はそんなにいないかもしれないですけど。
パスワードを保存する代わりに、パスワードが表示された画面を画像でスクラップしといてみたいなことをしてしまうと、
結構危ういですが、そこまでやってない場合、スクリーンショットの共有ツールとして使ってるぐらいであれば、
そこまで致命的ではないと思いますが。
一応、コセンスとかの情報が盗まれたということはないらしくんで、
画像にどれぐらいプライベートの情報を上げていたかどうかで、
これの影響の大きさは多分変わってくるとは思いますが、
とりあえず、例えばGoogleとかAmazonのサービス以外のところは、
生成AI時代の安全保障とポメラ
ハッキングされる可能性があるということの確率が飛躍的に上がったと思って使ったほうがいいという気がしますね。
そうですね。
だから、ローカル以外絶対使わないというのも、昔は心配しすぎでしたけど、
そうでもなくなっているなという感じがしますね。
そうですよね。
まあ、Googleだってわからないですよね。
わからないですけど、Googleがハッキングされるんじゃったら、
それはどこを預けてても多分一緒でしょ、きっと。
だから、どこにあげても一緒の状態が起こる可能性はありますよね。
そうですね。そこまでいったら本当にローカルしかないという、
自分でローカルで、ローカルネットワークの中でアクセスするみたいな、
すごく昔に帰ってしまう。
でも、それはその状況は間違いなく、
テクノロジーの飛躍的な進歩の闇の面ではありますよね。
逆に、ツールを開発して提供するかも同じように、
セサイアを使っても脆弱性なんか絶対に起こらんという形にせざるを得ず、
いたちごっこというところではありますね。
そうですね。
この辺結構、アメリカとかでは、超強力なセサイアは使えないようにしましょうという動きがありつつ、
当然その米国外というか、某大きな大陸の国はそういうウェイトがかかっておらず、
ということは、こういうことをしたい人はオープンウェイトの方を使えばよく、
守る方はちょっと能力が制約されたものを使わなければならないとしたら、
そもそもこう思ってるわけですね、こっちの光側が。
だからといってオープンにしたらいいっていうものでもないと思うんで、
非常にややこしい状況になっておりますね。
結局もう軍事安全保障と結びついちゃって、
一方だけがやめるわけにはいかないんですよね。
かなり危ういですよね。
こういう競争がどんどん出てきて、
もう誰も何かも何がどうなってるのかわからないし、
ちょっとでも穴があったら全てこじ開けられるというようなところになってきてて、
この負の側面の大きさが、ちょっと火にならないぐらいでかいなという感じはしますね。
だから本当に架空技術がいきなり民間に解放されちゃってるみたいな、
そんな感じですよね。
レベルのヤバさですよね。
まだここから業界全体がどう動いていくのか、
あと私たちユーザーがどう使っていくのかということがまた問われるとは思いますね。
楽しいコンピューティングの時代が懐かしいですね。
そうですね。今やったら一番楽しいコンピューティングは、
たぶんポメラじゃないかなと思いますけど。
いや、ほんとそうですよ。
ポメラはリナックスで動いてるらしいんで、
ポメラのリナックスでコンピューターすれば楽しいんじゃないですかね、きっと。
リナックスで動いてるんですかね。
たぶんリナックスで動いてたと思うんですけどね。
なんか誰かポメラでほにゃらら動かしたみたいなのを僕見たんで、
後ろでOSがなんか動いてるんでしょうね。
たぶんアンドロイドではないと思いますけど。
生成AIで作るアウトライナーとローカル執筆環境
たまたまノートで見つけた記事なんですけども、
Nautilinerのブリースシンクと読むんかな。
ブレーシンクかな。
ブレークと書かれてるのかな。
ブレストとか書かれてるのかな。
息の、呼吸のブレストですね、とシンク。
ブレーシンクって読むんですかね。
で、これ9月の5日に上がってる記事なんで、
僕なぜ見つけたかわからないんですけど、
いやー、アクタについて検索したんかな。
アクタの名前、アクタってどういうツールやったかなって検索しようともしてたら見つけたんですけど、
ノートのユーザーの方でアクタ7とツリーを使っておられて、
もうツリーはないんですけど、
横に伸びるアウトライナーという珍しいツールが使えなくなったということで、
自ら作られたということで、こういう話が本当に増えてきてるんですけど。
見た感じ結構ツリーに近いですよね、おそらくはね。
これやっぱり思うんですけど、
生成AIってね、もともとあったものを再現するのがめちゃくちゃ上手いんですよね。
当たり前ですけど、ユーザーのイマジネーションがもうカッチリしてるんで、
しかも技術基盤が過去にあったものなので、
あれ作ってって言ったら見事に作ってくれるんですけども、
ユーザーがかつてあったツールとかこういうのを作りたいっていうものを、
自分の手に合う形でアウトライナーが作れると。
一応公開されてるみたいなんで、
アップルストアで買い切りで使えるらしいですけど、
こういうのがちょこちょこ送っていくんだろうなとともに、
やっぱり昔のツール感を知っている方が作ると、
面白いツールが出てくるんじゃないかなとはちょっと思いました。
関連するんですが、僕もアウトライナーを作りまして、
リンクを反応忘れたな。
小さいアウトライナーですね。
そうですね。小さいアウトライナーが欲しいなと思ってて、
ポケットアウトライナーというふうに名前を付けたんですけども、
エレクトロンに似た仕組みでTAORIというのがありまして、
エレクトロンはChromeのエンジンを積んでるので、
極小で作っても100メガぐらいするんですよ、アプリケーションが。
TAORIはMac用のWebViewの機能を使うんで、
ブラウザが入ってない、梱包されていないのでめちゃくちゃ軽いと。
同じものを作ったら5MBぐらいになるんですね、サイズ感が。
僕は最近TAORIで作らせてるんですけども、
アウトライナーをまずファイルで開きたいと。
ファイル単位で開きたいと。
ワークフローリーのようなクラウドにあって全部が一個というよりは、
これだけを扱う、このことだけを扱うものをファイルとして管理したいなという願いがありまして。
それであれば簡単に作れるだろうと思ったら14分で。
14分。
消費した時間とトークン数が出るんですけど、
ASTRAさんに頼んだ14分でできまして、
MDファイルを開いて、いわゆるアウトライン操作が全部できて、
ショートカットキーとマウスの両方で操作できる。
本当に必要最低限のことだけができるツールを作りまして、
ファイルサイズがちっちゃいので複数窓を開くことも別に簡単にできる。
あまり巨大なアウトラインを扱うのは多分向いてないと思いますけど、
細かいアイディア出しとかその整理とかリストを作るときに使えるかなと。
ファイルでやることは決まってたんで、
つまりデータベースを背景に持ってということじゃなくてというところは決めてたんですけども、
テキストファイルから作るという一口に言ってもいろいろあるなと作りながら考えたわけですか。
3つパターンがあったんですね。
1つはMDファイル形式ということで、
全ての行頭に過剰書きのあれがついている、
ハイフンスペースが頭に入っていて、
スペースの数でインテントを制御するというタイプ。
テキスト形式はどうせ全部アウトラインなんだから、
最初のマークダウン基本もいらないと。
行がフラットに入っていて、
行頭のスペースとかでインテントを制御するというタイプ。
もう1個はJSON型といって、
テキストの形式はやめて、
JSON形式で1行1データとして、
データベースぽく扱うというパターンがあって、
この3つのパターンだけでも結構いろいろあるなと思ったんですが、
整合性というか、
JSONでやるとそれオンリーになってしまいますけども、
マークダウン形式でやっていると、
例えばObsidianで開いているリストを、
これでも開けるようになるなと思って、
いろいろ悩んだ結果、
両方を対応しようかなと思って、
JSONは一旦ほっといて、
さっき言った行頭に過剰書きのマークが入っているパターンと、
もう過剰書きのパターンが入っていないパターンの、
両方を読めるようにしました。
だからそれができるのもやっぱり自作ツールだからなんですよね。
Obsidianと共有するときは、
行頭に過剰書きリストが付いたほうがいいんですけど、
単純にテキストファイルで扱うときは、
むしろあれ邪魔なんですよね。
書かなあかんし。
だから一行目を見て、
一行目にマークが入っているか入っていないかを見て、
あとは処理を吉田にしてくださいという様式にしたら、
この形にできましたんで。
やっぱりあんまり考えつかないようなニーズに
対応できるのは素晴らしいなというのが一つと、
あとやっぱりアウトライナーとイコール僕ワークフローリーやったんで、
アウトライナーといえばこれ、それ以外は使わないという、
偏見に満ちたタイトで生きてたんですけど、
別に何種類あってもいいんだよなということを思いまして、
総合的に使うワークフローリーもよしですし、
例えばある執筆プロジェクトの4章のことを考えたアウトラインが、
僕のローカルファイルに入って別にいいわけですしという感じで、
使い分けるように今していこうかなと今考えてます。
特にあれですよね、他のファイルベースで文章を書いたりとか、
作業をしているものと組み合わせて使うというときには、
ワークフローリーよりもそういうもののほうが便利かもしれないですよね。
そうですね。僕、現行のデータはワークフローリーじゃなくて、
テキストファイルのローカルに置いてるんで、
今までアウトラインはワークフローリーになって、
現行がローカルになってというので、
なんかうーんという感じだったんですけど、
これだったら普通に整合できるんで、非常にいいかなという話と、
ちょっと関連するんですけど、ワークフローリーがMCPが使えるんで、
まずワークフローリー上でガガーってアウトラインを考えるじゃないですか。
例えば1章から6章ぐらいまでアウトライン立つじゃないですか。
で、僕の執筆スタイルだと、そこから文章用のテキストファイルを作る必要があるわけですけど、
手作業で。MCP使うとものすごく簡単に、
このアウトラインをベースにテキストファイルを作ってくださったら、
秒で全章分のテキストと持ってたアウトラインの情報が入ったものが
作れてしまうということで、
クラウドにあるデータを参考にしながらローカルのテキストファイルを
1命令だけでできてしまう。
これはすごくいいなと思いますし、
逆もできるんですね。
言語ファイルを読んで、
ワークフローリーのアウトラインに反映してて、
それも叶うんで、
今まで自動化が難しかった接続っていうのができるようになっているのはすごいなと思います。
たしかに、そうですね。
いいですね、モダンですね。
そうですね、これ結構モダンで、
しかも新しい何かパワフルなツールを作っているというよりも、
2つの接合するパイプラインを作ったという感じで、
既存のツールをまた使ってみながら、
新しい使い方ができるというのが、
なかなかいい感じかなという気がしますね。
なんかスマートですね。
モダンなやり方してますね。
あと関連して、
いろんなものが関連。
同じく、
ブログを超えた個人ウェブサイトの再構築
Astraを導入して、
1ヶ月だけプラスプランに入ったんで、
Chat GPTの。
だから余ってるわけですけど、
別に本格的に使っているわけじゃなくて、
生成AIっぽい文章を何とか作ろうという、
むなしい努力の、
もしかして無料やからじゃないかなと思って、
有料で文章を書かせたらどうなるかなと思って、
有料でもあんまり変わらなかったんですけど、
そのおかげでプランが余っておりまして、
せっかくなんで、
ウェブサイトをリニューアルしようと思ってたんで、
ブログではなくて、
ウェブサイトというのがここでのポイントなんですけども、
Rスタイルというのは、
ラスタ.ネットスラッシュ、
ブログスラッシュがルートなんですけど、
それより1個上に、
ラスタ.ネットといういわゆるページがありまして、
かなり昔に作ったんですけど、
もうずっと放置されてまして、
新刊の情報も更新されておらず、
ずっと気にはなってたんですけど、
直そう、直そうと思ってたのを今回直しまして、
情報をいくつか集めて、
自分の昔懐かしい、
僕はホームページという言い方を採用したんですけども、
昔の私のホームページというのを作りまして、
リンク集みたいな感じになってるのと、
ブログ形式じゃない文章とか、
僕、かつて今日の一言というツイートでよくつぶやいてたんですけど、
それを集めたようなコレクションページとかっていうふうに、
時系列でどうこうというよりは、
単発の文章とか、
それ自分の情報を集めたものっていう形の文章も、
上げていけるようにしたいなと思っておりまして、
これは僕はブログより一つ上に上るという表現をしているんですけど、
ある時期から自分のウェブサイトイコールブログになってたんですよね。
はい。
それも世間の風潮からしてそうなんですけど、
でも実際はブログはウェブサイトの一つの部品、
部品と言ったらいいですけど、
一つ形というか、
そうですね。
部屋の一個の部屋なんですよね。
それより実は上に自分のホームページ、
ウェブサイトという概念があったはずなんですよ。
でももうブログ作っといて、
ブログに例えばアバウトページとか入れときは、
もうホームページみたいになるみたいな感じだったんですけど、
ワードプレスは一応それが固定ページみたいなのがあったんで作れたんですけど、
ワードプレスをやめて自作のCMSを使っても、
結局その状態になってたワードプレス感を引きずってたんですけど、
それをやめて上位のホームページを作ろうとなったときに、
デザイン空間が広がったというか、
ブログを作るとなったら、
記事を時系列に縦に並べるしかないわけじゃないですか。
極論で言えば。
でもウェブに上げられるものってもっといっぱいありますし、
もっといろんな形があるはずなんですよね。
それが非常に記事を上げるみたいなことしかしていなかった。
それは僕がウェブ作りっていうものを仮に概念を定義したときに、
非常に狭い領域でしかやってなかったなと思って。
そもそもブログは記事なのかっていう話を前から前にしましたけど、
仮に記事だったとして、
記事以外のものももっとかけちゃっていいんじゃないかなというところを思い至りまして、
だとしたらそれを受けるオブジェクトはブログじゃないだろうと。
ホームページって何度読んでもいいんですけど、
それを一つ上の概念をもう一度復興していこうかなということを考えております。
いいと思います。昔はそうでしたよね。
そうですよね。
たぶんみんなWordpressを使うようになってそうなっちゃったんじゃないかという疑いを持ってますね。
ブログイコールサイトのほうが管理はもちろん楽なんですけど、
表現形式がやっぱり限定されてしまう。
コンテンツを縦に一列に並べる。
しかも同質のコンテンツを一列に並べるという発想に制約されてしまうというところがあって。
今も例えばノートでアカウントを持ってる人はそれしかないわけですよね、基本的には。
トップページみたいなのがないわけなんで。
たしかたくさんの昔のページもトップページありましたよね。
ありましたよ。
ブログの上にあるページがありましたよね。
ありました。
そういうのを復興していったほうが、もっと作る楽しさがあるような。
僕は作るの楽しかったんで、作る楽しさがあるような気がするなとちょっと感じております。
そうですね。
僕も本当にブログはその中の一部屋だったんですよね。
そうですね。
そこにカチッとした整理された記事に収まりきれない断片みたいなものを書く場所としてブログがあったつもりだったんですけど、いつの間にかそっちがメインになって。
なってますね。
で、あれはホスティングサービスの終了とともに巻き添えになったんですけど。
ソネット?
ソネットのそうですね。
ブログじゃなくて、レンタルサーバーを借りるというのがどうしてもそのとき嫌で、そのホスティングサービスを使ってたんですけど。
そういうものは当然ながらサービスの終了とともになくなってしまうので、そうやって失われたものがたくさんあるわけですよね。
やっぱり楽しみ方は記事を書くだけじゃない、ウェブに何かを作っていく楽しさが多分あったはずなので。
さっきのオブシリアン界隈でデジタルガーデンという方がなされるわけですけども、デジタル上でガーデニングするということですけど。
その行為が指しているものも非常に狭いというか、別にいいんですけど、記事を上げていくというところになってて、ページというものの大枠を作り込んでいくということではあんまりないという感じがしますんで。
もっと広く捉えたほうが遊びがいがあるんではないかなとちょっと考えてますね。
そうですよね。別にみんな普通に写真とかあげてましたからね。
あげてましたあげてました。
インスタとかそういうものの以前の時代にはね。
トップページにいろんな、昔はカウンターとか訪問者カウンターとか切り板とかもありましたし、今何言ってるんだろうこいつという感じだと思うんですけど。
やっぱりあそこに何をどう置くのかとかっていう構造の作り方そのものが表現やったと思うんで。
だから文章、記事だけで表現することも別にいいんですけど、もうちょっと面白い箱庭感が出せたほうが個人サイトというものに近いんじゃないかなという気はしますね。
こんなとこかなニュースとしては。
テスト駆動開発を執筆に応用する
本編なんですけども、新しい概念ではないんですが、テスト駆動式執筆ということが言えるんではないかということがブルース界で極小の領域で盛り上がってたわけですけども。
そもそも僕は結構プログラミングの発想と執筆の発想っていうのを結びつけて発想することが多いんですけども。
テスト駆動というのも一応知っておりますんで、それを執筆に利用できるというか、似てる部分があるなというのをずっと感じてまして。
テスト駆動開発ってご存知ですか?
一応概念は知ってるつもりです。
基本的にコードはまずコードを書いてうまくいくかどうかをテストしてうまくいったらいいですねっていう感じで進んでいくんですけど、テスト駆動はそれを逆転させると。
逆転かどうかは知らないけども。
まずテストを書くと。
マストテストを書くっていうのはすごいことで、コードを書いてないのにテストを書くんですね、実際の。
コードを書いてないからそのテストは絶対にエラーが出るんですね。
それはレッドシグナル、赤信号という状態で、そのエラー、赤信号のエラーを消そうというところからコードを書き始めていくという流れになっていると。
すごくめんどくさいコードをするわけですよね、それは。
というか、脳の実感でいうとコードを書きたいっていう感じになるわけですけど。
もう頭に浮かんでるコードを書きたいっていう感じなんですけど、先にテストを書いて、
必ずエラーになるテストを実行して、レッドランプを確認してからコードを書いて、実際に実行を通るかどうかを確かめると。
しかもそんな場合でも、まず絶対に通るような簡単なところから始めて、少しずつ抽象度を上げていくように進めると、
緑、緑、緑、抽象化が1個上がったら赤になったっていうときに、ここが赤になるなというふうに状況の切り分けができるとか、いろいろメリットがあり、
もう1個はそのテストのコードは、メインのコードとは別の系統で保持されるんですね。
例えばメインJSみたいなのがあったときに、メインスラッシュテストJSみたいな別のコード系ができると、
それを実行するとコードが実行されるわけですけど、ということはテストのコードが実装の記録にもなるんですよね。
テストが増えていくたびに実装のログが残っていくみたいな感じになるんで、実装のログにもなるというような機能があると。
いろいろテスト駆動開発はめんどくさいことがありつつも、コーディングにおいては有効だということが言われてまして、
生成AI時代にもテスト駆動がいいぞみたいな話は聞いてたんですが、僕はやったことはないんですけども。
そのような先にテストを書くと、自分でやると分かるんですけど、今このコードで何を書くべきかがかなりはっきりするんですよね。
漠然としたんじゃなくて、あのテストに通るためにはどう書けばいいかっていうふうに思考が切り替わっていくと。
そうすると結構クリアー、ソリッドな思考でコードが書けると思う効能があるんですけども。
それを例えば執筆に置き換えたときに、執筆におけるテストは何かをまず定義しなければならないわけですが、
案外だから、いわゆる一般的に使われるアウトラインは割とテスト駆動的なところがあるなとちょっと感じまして、
小立てを考えるときに、例えば導入基礎応用みたいな流れを仮に考えたときに、この部分を理解させるみたいな概念Aについて理解させるという一つのテストを設定し、
その後本文を書いて、その本文は確かに設定したAを理解させるに足り得るかと確認すると。
その確認するときは人間が読むしかないんですけど、読んでわかるようになってるかを確かめて、それでOKだったら次に行くという。
このAを理解させるというのは、いわゆる仮見出しというか、本物の見出しではないんですけど、そこの文章に与える役割というか枠組みなので、
そのようなテストを並べていくアウトラインがあれば、文章を書くサポートにはなるなと思うんですよ。
ある種の本の内容によっては非常に有益ではないかなと、まず個人的には思います。
ただ、そもそも何を考えようとしているのかがわからないときはこれは使えないよなとちょっと思うわけですけど、
この漢字は把握されますかね。
ある種は便利やけど、必ずそういうわけではない感覚っていうのは理解してもらえると思いますけど。
書き手によるテストと文章の目的
はい、理解していると思います。
ここ、同じようにこれはテスト駆動じゃないですけど、文章を書き終わった後に見出しをつけることをするわけですけど、
これもテストしているような感じがするんですよね。しかし後出しのテストですけど。
この文章はどんなテストを通っているかというふうに逆に定義している。逆テスト駆動方式というかな。
この文章が当初想定していたテストに通っているかどうかじゃなくて、この文章をOKにするテストとは何かっていうふうにして、
それを見出しとする、タイトルにするっていう逆駆動も僕の文章の書き方ではありますね。
これはテストを使うというパターンですけど、そもそもテストを先に作れないパターンで書いていくときにもアウトラインは役に立つというのがたくさんの長年の主張だと思うんですが、
アウトラインプロセッシングはむしろそこに注力があるような気がしますね。
そうですね。何をもって文章のテストとするかによってそこは多分考え方が変わってくると思うんですけど、
さっき暮らしたサインが言われた、見出しごとの機能を提示していくみたいな。
ここでこのことをまず前提としてこれを理解させる。次でその理解した前提のもとに自分の議論を提示して、それを論争していくみたいなパートごとに機能を。
このパートはこういう機能になるっていうことを定義して、それに応じて書いていって、その定義した機能をちゃんと果たしているのか確認するみたいなのっていうのは、
多分ある種の論文の書き方で推奨されてたりする、アウトラインの一種だとは思うんですけど、見出しとそこのソード部分の戦略を書くみたいな方法っていうのは多分あると思うんですよね。
多分それって、それをテストだと捉えれば多分それが文章におけるテスト駆動と言ってもいいのかもしれないんですけど、多分目的によって、多分そのやり方が向く文章と向かない文章は多分あると思うのと、
あとその書き手のタイプによって向くのが多分ありますよね。だから、そこを見極めないと逆に書けなくさせてしまう文になる。非常にそのメンタル的なところに影響を与えると思うんで。
機能を先に定義するというのはまさに決められたアウトラインに従って書くのと同じことになるので、メンタル的に。それがむしろ書くことを阻害してしまう場合があるということを理解した上でやる場合によってはすごく有効なんじゃないかなという気がしますね。
ここをどう使い分けるのかというパターン、まあ議論が一つあるのと、あとさっき言った書いた後でテストを考えるという方式も多分あって、それは見出しをつけるために必要だと思うんですけども。ということは、前にしろ後ろにしろテストみたいなのがあるということなんですよね、きっと。
そうですね。仮に僕がそれをやるとしたら、後からですよね。一旦書いた後で、この部分はどんな機能を果たしているのか、もしくは果たそうとしているのかというのを、見出しプラスちょっとしたその部分の戦略でもなんですけど。
文章の上の階層を加えてみることによって、書いたことに、この後さらに必要なことは何かとか、文章全体の自分がやりたいと思っていることを満たしているのかどうなのかっていうのが後からわかるようになると。そうすると今度はそれくらいで足りてないものをその後追加する。
そうすると、わりにうまく回るような気がするんですけども。実際にそれに近いことをやってると思うんですけど。個人的には最初からこの部分はこうで、この部分はこうでってやってしまうと、おそらく僕の場合は書けなくなると思うんで。
そうなんですよね。だから、不向きと文章の質というか目的によって、この二軸が関わってくるんで、どうとは言いづらいんですけど。僕はブログの記事の場合はおそらくテスト駆動では、後からテスト駆動ですし、後から駆動の場合はもう後からですらないですけど。
たぶん小説みたいな書くときも同じですけど、書籍、書き下ろしの書籍を作るときは最初テストを考え、書いてテストを再定義するという、もうちょっとテストの比重が大きくなっている気がしますし、だから書けないんですけど。
意図したいい企画案の方向性っていうのがあって、極力側に沿わせる必要があるから、テストみたいなのはまず必要なんですね。これは自分が当初想定してた、予案としていることと合っているかっていう判断軸が必要ですけど。
でも結局書いてて変わることもあり、そこのテストを再定義する必要があるわけですけど。テストを再定義する必要があるという概念があった方がいい気がするのかな。何となく書いているのは一番まずい気がするんですよね。
今これはテストが変わったなっていうふうに思えた方がいいんじゃないかな。自分がこれは何を書こうかがだんだんわからなくなってくるじゃないですか。特に文章を直すのに時間がかかっていると、なんか当初自分は何をしようとしてたんだっけって思うことが僕はあるわけですけど。
直しすぎてわからなくなっちゃうことはありますよね。
だから一回テストを意識して、継続なのかテストを変えるのかという意識を、もつなりでは文章化しておくことは、わりかし迷路に迷いにくい気がしますね。
なんとなく直してしまうんですよね。なんか違うなーと思ってなんとなく直してて、そのなんとなくの方針がわからないから。永遠に迷路に入ってしまうことがあって。
そこもそのテスト駆動開発における、要するにテスト駆動、テストドリブンですよね。テストにドライブされるわけですよね。
そうですね、テストにドライブされるわけね。
文章におけるそれというのは、テストに駆動されているんだろうかという感覚ありません?ありませんというか。
開発、例えばプログラミングだと、要するにテストを、僕ちょっとプログラマーじゃないんで、素人の子供として聞いていただきたいんですけど、テストを通るか通らないか。
その場合一応、書かれたテストの要件を満たしたらOKということになるわけですよね。最初にそのテストがあって、後からそのテストの要件を満たせるように書いていくと。
で、その文章におけるテスト駆動って考えたときに、そもそもここを満たした、ここを満たしてないっていうのって、かなりやっぱりプログラミングに比べて曖昧になりますよね。
そこって結構大きい違いになるんじゃないかと。その曖昧さがあるからこそ、テストからテストに駆動させるというのは難しい気がしちゃうんですけど。
もやもや感を出発点にして書き始める人がいるわけですね。それは僕なんですけども。このことについて分かってないから考えたいというタイプで執筆していく、もやもや駆動というのがあるとしたときに、おそらくそれではうまいこと文章を書けないタイプの方が多分いらっしゃって。
自分が何を書こうとしているのかをまず明確にする。例えば、コンビニのプリンについて書きたいではアバウトなんですよね、基本的な場合は。
それをおいしいと言いたい。おいしいと呼んだ人に納得してもらいたい文にするという方向性を決めることで書けるタイプの人がいて。この場合、テストはあなたはこの文章で何を言わんとしたいのですかを考えましょうという提案として受け取ればいいんじゃないかなと思うんですけど。それで僕は逆に書けないですけど、それで書きやすくなるタイプも多分いると思うんですよね。
それはなんとなくアウトラインに基づいて書くとかに近い気がしちゃうんですよね。僕の感覚だと、アウトラインを作ってそれに基づいて書くというのは、ただプログラミングのメタファーで言えば、昔ながらの使用書があってフローチャートを書いて、入力があって出力があって、っていうあれのイメージなんですよね。
ただ、おそらくテストの時期本気で採用する場合、一般の人たちが作るアウトラインの項目の記述の形が多分変わってきて。つまり、さっきの話で言うと、一般的なアウトラインの場合は、領域Aとか領域Aの説明みたいなことを書くわけですね。そのアウトライン項目上に。
でも、それでは結局、その文が何をしようとしているのかは、はっきりしないわけですね。それを、Aについて初心者にも理解できるようにするとか、理解させるって書けば、その文章の意義、目的がよりクリアーになって、どう書けばいいのかの考える戦略になりますけど、領域Aではすごく漠然としてるわけですよね。
その漠然としたものを、ある種方向性を定めるように意識を変える。ただ、領域Aと書くんじゃなくて、より具体的に。タスクを単語じゃなくて文で書くみたいなのと多分近いと思うんですけど、より具体的に、そこで何をしようとしてか、自分の意図、インテントをはっきりさせるみたいな役割じゃないかなと思いますね。
そうすると、スクリブナーって割にそういう使い方もできるように作られてる感じがしますね。
本文とは別にシノプシスを書けるんで、おそらくそのふうに定義すべきことでしょうね、きっとね。
そうですね。シノプシスって一応概要を書くのが一番標準だと思うんですけど、あそこに戦略を書いてもいいわけですよね。
そうですね。
戦略を、特に日本の場合、ロジックを教えてもらわない以上に戦略的な感じがあんまりなくて、随筆なんです。随筆を悪く言ってるわけじゃなくて、ズレズレになるままに書く。
3文目ですね。
それではね、やっぱり書きにくい場合が多いと思いますね。ソリッドな、効果的、エフェクティブな文は書きにくいと思うんですよ。
ここの文章でこれをこのような意図で書くんだっていうことがないと戦略って立てられないんで。
そうなんですよね。
戦略を立てないで書いてる人間が言うことではないんですけど、でも自分の文章を後から点検してるときは、ちゃんと戦略できてるかを後付けで確認することはもちろんありますけど、
自分が言わんとしてることに対してメッセージの量が少なすぎひんとか事例が多すぎひんかみたいなことは確認しますけど、
つまり戦略的観点はありますが、それを先に立てない。立てへんからもたつくんですけど、立てられないから仕方がないんですけどね。
最初に立てられないから仕方がないんですけど。
でもやっぱりお書き手の中の訳文企画案の段階で、1章から6章までのその機能の役割を定義できて、それによってあとはブロックコートに書いていける人もおりますし、
それをもうまさしくテスト駆動式実筆をやっておられると言えると思いますね。
僕とザクさんとどっちかっていうとそのやり方では書けない派の人間なんで、ちょっとネガティブな評価を僕は知ってしまいますけど。
僕から見るとカトクラシスさんが書けそうな気がする。でも本人が言ってるんだからそうじゃないでしょうね。
書ける時と書けない時がありますね。当たり前のように自分が分かってないことはこれはできないですね。
自分の理解の最前線を書こうとしたら、これはまずできないと思います。
それはプログラマーがどんな機能をつけようか分かってないのにテスト駆動なんてできないということの1個、手前のレベルなんです。
ある程度書くことが分かってて、本人の中に上手くいくロジックの道筋っていうのがあるとしたら、それをテストを確かめながら書いていくっていうのは非常にクリティカルなやり方な気がしますね。
なるほど。だから僕が3文的なだけでは書けないタイプのものを書かなきゃいけなくなった時に、でも僕3文しか書けないんですよね。
3文っていうか何を書いても随筆になっちゃうんですよ。そのままだとダメなので。
そういう時に書いた後で見出しをつけて、そうするとアウトラインができるわけじゃないですか。
その見出しの長さにもよりますけど、例えば大見出し、中見出し、小見出し、小、節、高みたいなのがあったとした時に、
一番小さい見出しはまあいいとして、節レベル、中見出し程度のレベルに、実際にそれを使うかどうかは別として、リード文みたいのを全部入れてみるわけですよ。
本説ではこれこれこうしてこうしてこういうことを説明しますみたいなものを、あたかもそれを本文に載せるかの形で書くわけですよね。
それで書いた後で自分の書いたものを読み返すとそうなってないわけですよね。
だめだこれ。だからその時に一度書いたものをその後から追加したリード文に合うように書き直すという作業をすることによって、
3文でないというか、随筆でない風のものを結果的に作るという方法をとらざるを得ない。
それをやらないと多分そういうものを作れなくて。
そうですね。僕もまあわりかし、戦略的なものは一応立てては見るものの筆がそれについていかず、
テストそのものを再改訂することの方が多いですね。だから時間がかかってしまうんですが。
もっとテスト意識を読めればもうちょっと効率的になるのかもしれないですけど。
まあちょっとこれは意思で解決できる問題ではないので、なかなか難しいですけど。
でもやっぱり先にテストするか後でテストするかは別として、テスト意識って結構大切で。
自分がこれまで書いた文章があって、それがなかなか進んでないという時に、見出しをつけるんじゃなくて、
紙とかで、第1章はこれについて書いてるな、第2章はこれについて書いてるな、みたいなのを書き出した時があって、
その時にそれぞれの章は何か自分なりの問いに答えようとしているなと気がついたことがあったんですけど、
例えば人はなぜメモを取るのかっていう問いに、その問いにダイレクトではないですけど、ある事例を語ることによって、
結局的にその問いに答えている文章になっているなと。
一つ一度気づくと、じゃあ他の章もその問いに対応させる形で書けるんではないかみたいなインスピレーションが湧いてきて、
全体の構造に普及していくみたいなことがあるんで。
やっぱりそもそもこの文章は何を言わんとしているのかということを自らに問い返すということは、
後であろうが前であろうが多分有効な思考でしょうね、きっと。
間違いなく有効だと思います。
だからそこは多分賭けなさにあるんですよね。
自分が何書いてるかわからなくなってくるというところで混乱が引き起こされてしまう。
ただ僕はプログラマーではないしプログラミングもしないので、書くたることは言えないんですけど、
文章とプログラミングというかコードを書くときの一番の違いって、
僕のイメージだと目的もなくというか、筆が走って勝手に書いちゃうみたいなことは起こらないですよね、プログラミングではおそらく。
それは難しいところですね。
うっかり書くべきではないコードを書いてしまうことはありますね。
それはあるでしょう。
ある種の流れに任せて脱線してるわけですけど。
でもそれはもう明らかにいらないので消しますけど。
だから難しいなあ、それは。
本来ローカルの変数にしなければならないのに流れでグローバルに変…
そういう流れではありますけど、
うっかりといえばうっかりなわけですが。
だから完全にロジカルに展開していくだけではない人間的なものがカイムとはさすがに言えないですね。
ただ内容に影響を与えるかどうかで言うと、明らかに間違ったというか、機能不全のコードなんてすぐ消されますけどね、当然のように。
そうですよね。
ただそのわからないのは、まあだから目的がないっていうか、
例えば遊びでコーディングするにしても何かを作ろうとしている、作ろうとする何かはあるわけじゃないですか。
文章の場合ってそれもないことはありません。
ブログの場合はそうですね。
ただフレーズを書いているっていうことを。
ただ僕がわからないのは、
プログラミングでもありえそうな気がするのは、
何か目的を持って、例えばAという機能を実現するために書いていて、
ある処理を書くことによって、
あ、AじゃなくてA'の方か、
思ってたのとちょっと違うものにした方がいいんだなということが閃いて、
その目的自体が変わっちゃうっていうことはあるんですかね。
あると思います。
ありそうな気がするんですけど。
このテストを日本で紹介した有名な和田さんという方がいるんですけども、
その方が最近AIを使ってコードを書くようになったおかげで、
爆速になったけど、コードの理解が著しく悪くなっていると、
自分が書いているコードが把握できていないことが増えていると、
その理解不細というような言い方をされてたんですけど、
ある程度自分が書くことが必要やという話に流れるんですけど、
コーディングって書いてから理解することがあるんですよねと何度かおっしゃってたんですよね。
それ文章と一緒だなと思ったんですけど。
パッと思いつくと実装してコードを走らせてみたときに、
違うかったと、これはこういうことなんだと分かることがあると。
昔の脆弱な生成AIの場合、そこで止まったんですよ。
思ってたことが違うからというフィードバックが返ってきて、
どうしますかみたいなフィードバックが返ってきて、
初めてそこで応答することで、そうなってたんかというふうに手を動かさないようにして、
コードの実情が分かるから理解が進むということがあったんですけど、
最近の生成AIのエージェントがすごくて、
トラブったら自分で解決するんですよね。
あたかも最初からそうなってましたかのようなコードになるんですけど、
実体は違うんですよ。想定したものと違うものになっているわけですよ。
そのようにして理解と実体がずれていくという話で、そこの話題が出てきたのと、
コーディングでもやっぱり書いて分かることがある。
そのコードが持っている意味とか意義とかが、あるいは実現しようとしているものと、
自分が思い浮かんだ実装のズレっていうのが、
初めて書いて分かることがやっぱり出てくるという話をされているので、
それはやっぱり普通にあるんですよね。
多分だから、さっき例で言うと、コーディングにおいて、
例えば、if文書いてたらうっかりfor文書いてましたみたいなことはないですけど、
実装される機能のレベルにおいては多分あると思いますね。
このコードを書いて、こう実装したら、うっかりこういう機能が出てきたから、
新しくこういう機能を付け加えようと考えたっていうふうに、
機能のレベルでの思わぬ展開みたいなのは、多分普通にあると思いますね。
だから、働いているエプリアがちょっとずれているという感じですかね。
なんか書いてしまったことによって、
その目的がボトムアップ的に変わっちゃうみたいなこともあり得るという。
だから、フルのデータを取得する必要があったけど、
よく見てみたら、フルじゃなくて一箇所だけでいいってことに気づくとかっていうことにして、
データベースの取得の仕方そのものが初めからやり直される。
テストそのものが変わっていくっていうことは普通にあると思いますね。
なるほど。
だから、コードの場合は実行というのがあって、ランがあって、結果が返ってくると。
それによって、吉田氏とか副産物とかっていうことが分かってくると。
文章も同じなんですけど、何度も出てきるようにするとテストの中身が問題なんですよね。
で、文章のテストって読んだ人が理解するってことですよね。
脳内に何かイメージを立ち上げるとか、理解の構造を作っていくことが文章の役割。
小説であったら小説内世界を脳内に描くイメージングすることが文章の機能だとしたときに、
そのテストを行うのは大体書き手である自分なわけですよね。
コーディングの場合、テストを実行するのはCPUなわけですよ。
だから他者なんですね。コーダーからしたらテストの実行者は。
でも書き手は自分で書いた文章を自分の脳内で操作してうまくいくか判定するわけですが、
ここがうまくいかないことがあるんですね。
自分の文章を自分でテストしたときに、まず自分で書いた文章から自分で分かってしまうっていうのがありますよね。
他の人が読んだら分からないのに自分が書いたら分かるっていうことがあまり起きますよね。
これテストの心配ですね。
逆に自分がこの文章をテストするときに、さっきみたいに機能、文章の定義ができてないから、
この文章がうまく働いているかどうかの判断軸をまず持っていないからテストできないっていうこともありますし、
あと何回もその文章を読んでいるが故に、いいかどうかがもう分からなくなってくるみたいな。
そう、それもすごい多いんですよ。
CPU疲れみたいなのもあって。
だから本当の意味でテストしようと思ったら、誰かに読んでもらうしかないんですよね。
自分以外の、例えば編集さんっていうのはその役割で多分になってると思うんですけど。
そこのテストがうまくいかないことがあり得るというのが、人間の執筆のテスト駆動の問題というか、抱えているポイントであり、
それがうまい人が文章がうまいということだと思うんですけど。
他の人が読めるように読み合わせる人は、普通に読んで読みやすい文章を書ける人だと思いますけどね。
そうですね。
文章を支えるエンジニアリングと美意識
そういうプログラミングというか、エンジニアリング的な発想を文章を書くことに当てはめることの間違いなく有益なことがたくさんあるんですけど、
やっぱりやりようによっては逆効果になっちゃうこともあるだろうなというのを昔から思っていて。
でも一方では、そもそも例えばテキストエディターとかワードプロセッサー、ワープロというものは、
やっぱりプログラミング用のエディターがなければ、機能のほとんどはおそらくなかったわけで。
間違いなく。
そういう意味では最初から強い影響を受けて、プログラミングというかコーディングする人の発想の影響を強く受けてるわけですよね。
だから、すごく両面がある気がしますよね。
やっぱり見出しとか階層を作れるエディターと、例えば原稿用紙が画面に表示されるタイプのワードプロっていうのは、やっぱり想像力が全然違ってきますし、
原稿用紙がマス面で表示されるやつにテスト駆動式みたいな発想が出てこないと思うんですけど、
あれは随筆的というか、構造感がないんですよね。
もちろん文章のエディターの設定によって、原稿用紙型でも見出しが入るやつは普通にありますけど、
そういうものじゃなくて、純粋にマス目だけが並んでいて、ここに文字を埋めていきましょうという感じでは、
あんまりエンジニアリング感はちょっと薄いなという気がしますね。
そうなんですよね。ただ、前も文章エディターの文脈で何かその話出た気がするんですけど、
僕もずっとすごい、画面に原稿用紙表示するワープロとかすっごいバカにしてたんですけど、
作家の人が開発に携わったワープロで、
ワープロというかプロ向けの、作家向けのエディターみたいな原稿プロセッサーっていうのがあって、
400字×400字の原稿用紙を画面に表示するんですけど、結局、
かつ字用で組んだ時に、400字詰め原稿用紙、要するに20字、
1行に、あれは20字か、20字ですよね。
あの字詰めで書かれた文章が紙面で一番収まりが良くなるみたいな経験則があるみたいなことを言っている人がいて、
なんか全然違う意味のエンジニアリング発想だったりするんですよね。
あー、なるほどね。
それは別の意味ですごくプロっぽいというか、
プロの物書き、伝統的な日本のプロの物書きの発想が組み込まれているんだなという、
決して単に気分で原稿用紙表示しているわけじゃないんだなというのをちょっと思ったことがあるんですよね。
そうか、だからエンジニアリングにも実はない多様性があるというか、
ここまで言ってるのはコンピューターエンジニアリングというのは基本的に、
ソフトウェアエンジニアリングとかの発想であって、
工業学的な発想っていうのは別に他の領域でもいっぱいありますからね、もちろん。
そうなんですよ。
だから、原稿用紙なんて悪でしかないとならないことだと思ってて、
あれは要するに手書きで、日本語が結局漢字、金混じり文を手書きで書くときに文字数をカウントするための必要枠ぐらいのものなんですけど、
結構、特に昔のプロの物書きは、原稿用紙、どっちかというと400字じゃなくて200字図目ですよね。
そうですね。
あれで物事を量も測るけれども、筆筆のリズムもあれで作っているみたいなところがあるんで、
いろんなものの見方ができるんだなというふうに思いますね。
でも、ある量の文章を書いていくときに、まっすめが生むリズムはたぶんあると思いますね。
そうなんですよ。
エディターで数センチ超えてくると、自分がどこで何を書いたかわからなくなってくるんですよね。
位置感覚がロストされるんですけど、まっすめはたぶんそれがあるんだろうなという予感がありますね。
そうですね。
どうしても文章の叩頭点の入り方とか、区切り方もまっすめの影響を受けるはずなんですね、あれを使って書いていると。
今はもうデジタルなんだから、そんなもの関係ないかというと、
おそらく商業出版物に掲載されるような文章っていうのは、明治から原稿用紙で書かれた文章によって作られてきた歴史があるわけで、
それをもとに、今でも紙面というのは作られているところがあるわけですよね。
今はDTPで作られているとしても。
そこに掲載する文章を書くライターとか作家という仕事があるとしたときに、
実は決して無関係じゃないんだなと、そのとき思ったんですよね。
そうですね。雑誌とかのライターの方も、紙面の横幅文字数を考慮して、
エディターの横幅文字数を決めてから書くみたいな人もいますからね。
エンジニアリングも多様だという話は非常に面白いですね。
もう完全にソフトウェアエンジニアリングしか頭にないというのが分かりました。自分の中で。
いろんなエンジニアリングありますよね。
広く捉えれば、紙面のレイアウトとかデザインだって、その中で捉えられると思うし。
確かに。
で、そうすると、
僕が千葉雅也さんに話をかかったときに千葉さんが言ってた、
DTPソフトで書く。
はいはい、直接書くみたいな。
クォークエクスプレスでテキストボックスを先に作って、そこにはまるように書く。
そこにはまってかっこいいように書くみたいなことも、工技のエンジニアリングだなと思っていますね。
なるほどね。あれはだから、一見アートっぽく見えるけども、実際発想としてはエンジニアリングに近いのか。
近いというか、その両面持ってますよね。
ありますね。確かにそうだな。
で、おそらくそれによって内容が影響を受けるはずですよね。
それは間違いなくそうやと思います。
エンジニアリングの大義がアートなのかはちょっと分かりませんが、
定まった結果に向かって進んでいく道と、進むべき道を探求しながら進んでいくという2つの方策があったときに、
完全に二律が分かれているわけじゃなくて、
程度とかバランスで割合が入ってくるという感じがあるんですかね、これは。
そうだと思いますけどね。
プログラマーの人でも、逆にそういうアーティスティックな感覚を持ってプログラミングしている人っていますよね、たぶん。
たぶんコードを短くするとか、関数名とかを考えるのもちょっとアート寄りな感じがしますね、なんとなく。
そうなんですよ。すごいこの話をするの恥ずかしいんですけど、
大学卒業して一番最初の仕事、あれだったね、コンピューターの仕事ですね。恥ずかしい。
一応SEという名目だったんですけど。
コボルを書いて、レコードを書いてたわけですよ。
それ以前に研修でSEとか習ったりするわけですよね。
それを教えてくれる先輩がいたんですけど、
その人がすごいおしゃれな人で、かっこいいんですよ、その人すごくね。
コードもおしゃれじゃなきゃダメだというわけですよ、その人。
当時プリントアウトするんですけど、コードをプリントアウトして、見てみろと。美しいだろうと。
なるほど。
読めなくてもプリントアウトした文字が並んでる形が美しいだろうと。
お前らのとは違うだろうというわけですよね。
こういう美しいコードが性能もいいんだと。
すごいね、そういう感覚を持って仕事をしてるんだなという印象になってます。
でも実際、機能帯みたいなのはあると思うんですよ、コーディングにおいても。
あるでしょうね。
ごく単純に雑なコードは人間が読みにくいっていうこともありますけど、
そこで行われる処理を人間が理解していたら綺麗に書けますし、
そうじゃなかったら綺麗に書けないということがあるんで、
機能的なコードと見た目の美しさの相関はある程度あると思いますね。
いいでしょうね。
アウトラインって見た目が、やっぱりアウトラインも美しいアウトラインと美しくないアウトラインがあると思うんですけど、
やっぱり読みやすく面白い文章のアウトラインが美しいと思うんですよ。
例えば美しさは、4章立ての項目がすべて4項目で揃っているというシンメトリー的なことだけではないということですね。
そうですね。でもシンメトリー的なことが大きいかもしれないですね。
それを意図していなくても、読みやすくわかりやすい文章、文学的な意図を持ったものは別として、
読みやすくわかりやすい文章は、おそらくアウトラインにするとシンメトリー度が高くなる傾向があるとは思いますよね。
思考のエンジンで出てきた話ですけど、ある部分だけやたら長いからみたいな話で、
見た目の形式、文字数の整理と内容の整理は一貫しているということですね、要するに。
だから書いた文章のアウトラインを後から作ってみたときに、
だいたい3階層ぐらいできているのに、1箇所だけ6階層ぐらい、すごい深くアウトラインが折れちゃっているようなところがあったとしたら、
そこは多分文章的に何か問題がある可能性が高いみたいな。
これまさにその通りだと思うんですよね。
コーディングにもそうですよね。だから、ある関数を単関数で短く作っているのに他は全部。
1個だけものすごい長い関数があったら、すごいなんか変やなって感じしますからね。
でもそのアウトラインの美しさ、インデントされたアウトラインの見た目の美しさと、
見た目の美しいコードっていうのはやっぱり共通点があるような気がしますし。
コードもインデントして頭揃えるじゃないですか。
そうですね。
あのパッと見の美しさって、すごくアウトラインの美しさによく似てるなと思うんですけど。
文章を書くときのアウトラインの問題は、見た目の美しさが先に優先されて、
内容をそれにギューギューに合わせることが起こるわけですよね。
本当にそこが面白いところなんですよね。
美しいアウトラインを先に作ってそれに合わせて書けばいいかというとそうじゃない。
でも結果的に読みやすく面白い文章は、それは奥田さんの言ってたことですけれども、
結果的には読みやすく分かりやすい文章は、アウトラインがそういう見た目になる可能性が高いっていうのは、
なんか本当にいろんなことを示唆してるなと思いますね。
だからテストで言うとアウトラインの形が最終的なテストになっている。
テストと捉えればね。
テストの一つになっていて、OKかOKかの判断を、ある種の美的感覚を頼りながら確認していますし、
言ったらかなり俗人的というよりはある程度形式的に判断できますよね、見た目の方のね。
結構形式的ですよね。
それは非常にいいことの一面はありますよね。
でも、日本語の作文技術を書いた本で、つまり論文ではなくて、日本語の文章技術を書いた本で、
この文章の機能とか意図を考えましょうみたいなことの示唆を受けたことがないですね、僕は。
ないかもしれないですね。
論文の書き方の文脈でしか見たことがない。
論文はありますよね。論文はまさにないですね。
いわゆる昔からある文章独本的なもので、だいたい文学的というか。
微文を示唆する。文そのものの美しさであって、
そこの機能主義的観点はむしろ部粋みたいな感じが扱われ方がしてる気がしますね。
そうですね。そうか。
でもやっぱり普通に文章を書いてて、自分が書いた文が機能してるかどうかのジャッジはしてると思うんですけどね。
してると思います。
そこを言わへんと、たぶん上手いこといかへんという気がするんですけどね。
そうですね。
なんか詩っていうと、あの誰だっけな。
向井里史の文章独本っていうのがあった気がして。
ちょっとそういう感じのことが書かれていて。
そういうふうに書かれた文章を高く評価してるような印象があったんですけど。
ものすごい昔に読んだのでちょっとあやふやですが。
たぶん向井里史の文章独本だったと思いますね。
割に何て言うんでしょうね。
それこそ村上春樹とかを評価してたような。
いわゆる日本文学的な文章じゃない、どういう言葉で評価したのかちょっと思い出せないんですけど。
そういうのが強いて言えばそれがあったかもしれないですね。
なるほどね。
生成AIによる文章評価と人間の技能
だからやっぱり文章を書くときに語彙とかはもちろん必要ですけど、
やっぱりその一個一個の文章を見る目なんですね。
自分が書いた文章を見る目がクオリティを担保しているんだなと。
テスト感というかね。
それがクオリティに影響をしていて。
やっぱり最近はそうではないですけど、
一昔前の生成愛で出された文章はそのメキギがやっぱり働いていない感じがするんですよね。
ただ出しただけという感じ。
逆に、逆にではないけど、生成愛が書く文章は非常にシンメトリーなんですよ。
段落が。段落がというか、文が。
ほぼ3つ4つ全部同じ長さなので段落が続いてて。
そこはね、やっぱりリズムがないんですよね。
そうなんですよね。
リニアな文ではシンメトリーさえでもリズムが重要なんですね。
凸凹のリズムが重要なんですね。
それを構造で見たときはシンメトリーになってないといけないというようなことなんかなという気がしますが。
そうですね。
形式がすごいシンメトリーなんだけど、
読むとそのシンメトリーな形式の中身がそんなに変に混ざってたりとか。
確かに。
ものによるでしょうけれども、そういうものが多い気がしますね。
難しい。難しいと言って怯えさせるつもりはないんですけども。
片方の自分は文章なんで好きに書けばいいと思いつつも、
一応職業人として文章を書いてる自分としては、ある種の目が必要だよなという思いもあるという感じがしますね。
ひとつあれじゃないですか。
木村伊澄さんのワープロ作文技術は、いわゆる論文ではない日本語の文章を書くということの中で、
すごくバランスよくエンジニアリング的な発想と、
従来型の文章読本の要素と、
文章読本って言っても、従来型とはいわないけれども、なんて言ったらいいんでしょうね。
エンジニアリング型ではないものが含まれている。
それをバランスよく含んでいると言うと、木村伊さんの本はあるなと思いましたね。
まず本自身がコンピューターの本ですからね。ワープロっていう。
彼自身が工学系の人ですからね。
だけど、昔の主催の人ってそうですけど、
結構文系的な意識と知識が非常に深い人なので。
プログラマーも美意識を持っているということを考えると、
エンジニアリングの発想だけだとまずいということなんですよね。
アート感覚だけだと、今度は形にまとめられなくなってくるので、
エンジニアリング思考とアート感覚の対比をしたときに、
両方を持っておく。偏らせすぎない。
それで100%エンジニアリングで文章を書ける人がいたとしたら、
それでいいと言えるかどうか言い切りたくない気持ちはあるんですけど。
エンジニアリングを突き詰めると、生成AIに生成させるってことにならないですかね。
いや、わかんないです。逆にそれ聞きたいですね。
エンジニアリング発想が自分の中にやっぱり足りないんで。
最初にテストを書けるぐらいまとまっているのであれば、書かせられる気はしますけどね。
僕らの場合は何を書こうかまとまっていないので、そもそも無理ですけど。
もし最初に全部機能を定義できるぐらい自分の論識が明確であれば、
そのまま生成させても変わらない。
その人がアウトラインを立ててその通り書けるんであれば、
プロンプトでアウトラインをもとに生成させても変わらない仮説は一応立てられますが。
なるほど。
それは本当に急な人だと思いますけどね。
そうですね。だから、それができるように見えている人も本当に100%そうしてるわけじゃないと思うんですよね。
そうですね。たぶんそうやと思います。
ただその頭の中でどういうふうに動いているのかわからないんで。
アウトラインじゃないですけど、
昔、糸井信里さんがエッセイみたいなものを一本書くのを実況中継みたいにしたことがあったんですよ。
面白いね。
本当に頭から始めて終わりで終わる。
すげえな。
ああ、それができる人なんだなと思いましたけどね。
だから、糸井さんはもちろんコンピューター以前から書いてる人ですけど、
手書きでも同じものが同じように書けるんだろうなと思いましたけどね。
まあ一応でも、糸井さんは随筆寄りですけどね。
随筆寄りですね。
だから可能という感じはしますが。
なるほどね。確かに。
ロジカルな数万字の展開をそれで可能かどうかは別の話じゃない。
別でしょうね。
別でしょうね。
ただ、そういうものをもし書くとしたら、アウトラインというか目次案を作って、目次案通りに書けそうな気がそれを見てたらしましたけど。
どうですかね。ちょっとわからないですけど。
かなり難しいんじゃないですかね。
エッセイは結局、途中何を書いても成立するのがエッセイですからね。
エッセイだし短いものですからね。
大きさ長さっていうのは人間の認知に対する挑戦なので。
しかもそこは時間というファクターが入ってきますよね。
自分の考えがその時間の間に変容することがあり、論史の一貫性を保つのが非常に難しい気がしますけどね。
超大作を手書きで書いた昔の人というのは一体どうやっていたのかというのは本当に思いますけどね。
ただやっぱり小説に関して言うと、やっぱり統合してみると矛盾が多いみたいな話は聞きますけど。
小説なり作品の辻褄が合ってないことは結構あるらしく。
統合っていうのは。
あの場面と離れたあの場面を見たときに、あれ?あの人ここにいるわけないやんみたいなことが結構たびたびあるという。
で、読んでる人は気づかないわけだよね。要するに飛んでるから。
あるでしょうね。
論文とかはもっと精査されてっていう。でもあれも結局一回で通るわけじゃなくて、
何回も佐々木とのやりとりで論事が整う形にブラッシュアップされて、多分出版されてるんで。
頭が立派とドーンっていうことは、やっぱりどっか破綻を含むもの。
小説は別にそれでも、一回一回のページのやりとりや場面やセリフが良かったらそれで成立するメディアですからね。
そうですね。
まあでもね、やっぱりデジタルなしで長いものを昔は書いていたわけですから。
あれはすごいですね。
ただ逆にデジタルで編集できるから破綻が生まれちゃうってこともあるんですよね。
あると思いますね。破綻が気になるようになってしまうというのもありますね。
っていうかね、編集してある記述を後ろに持っていったんだけども、
その途中の記述が実はそのある記述が前にあることを前提に書いていてそこに気づかずに、みたいなことはむしろ手書きよりもデジタルで起こるかもしれないですね。
そうですね。それはそうですね。
それがね、アウトラインをぐにゃぐにゃ動かすと起こるんですよね。
まあそうでしょうね。
それがアウトラインの危険なところの一つで。
それは、たとえば生成AIが移動させたときに、ここはこの記述がおかしくなりますよと教えてもらえば助けになるんですかね。
なると思いますし、そのチェックには生成AIが役に立つんじゃないかと。
まだ本当に長くて真剣に書いたもので、それを自分でやってみたことはないんですけど。
なぜなら頼まないことまでチェックしてくるから。
それはいいね、それは見なくていいんだよみたいなことが起こるんで、その調整をするのが面倒なんで結局本番では使ってないんですけど。
でも、本来はそれに役に立つはずだと思うんですけどね。
そうですね、だからいわゆる昔の場合は、移動させたときに含まれているキーワードで検索して、前後見て文脈が合っているかどうか確かめるみたいなことを人間がする必要があったわけですけど。
彼らは文脈を読めるので、移動した記述と整合性があるかどうかを確認させること自体は多分できるでしょうね。
そうですね。
それでも今、昔と違ってまさにキーワードで検索をして、今書いてるこの前に同じキーワードが出てこないかとか出てくるかっていうのをチェックが比較的簡単にできるようになったのはやっぱり、
仮にAI使わないにしても、やっぱり昔から見れば大きな進歩ですけど。
そうですね。でも逆にそれによって人が神経質になっていくというのは。
そうなんですよね。
でも完全にいくのは諸刃の刃という感じがしますけど。
そうなんですよ。
先生、また次回にも言いますけど、最近、執筆プロジェクトって原稿ファイルとか、ルールメモとか、アイデア書きのラフスケッチとかいろいろなファイルを扱うんですけど、
Macのファインダーって扱いにくいんで、ファイルの情報を集めたインデックスHTMLを生成AIに作らせてるんですね。
そこにもファイル一覧があって、説明書きがあって、でも別に何も言わなくても、例えばその章の情報を載せてくださいって言ったら、その章の要約をパパッと書かれるわけですよ、彼らは。
文脈を使った情報のまとめには非常に有効なので、原稿そのものではなくて、移動の操作とか、本来ならアシスタントがいたら頼んでやってもらうようなことをやってもらうのって、非常に有効な気がしますね。
そうですよね。
テスト駆動としても、生成AIが少なくともこの文章をこういう意図で書いてるんだけど、どのぐらい機能してるかみたいなことを聞くこと自体は悪くはないと思いますけどね。
そうですね。
人間に読んでもらうのが一番いいとは言いつつも、人間はその暇ではないので。
そうですね。
あとはどれだけ彼らのしょうもない意見を聞かずに、端的にコメントだけもらえるようにするかどうかという問題がありますが。
だからまさにそこの技術が必要ですよね。そうなんですよね。
高性能なものはあれによるか。
結構ね、ChatGPT-6さんは割に端的ですね。そんなにいやいや言ってこない印象がありますね。
あと1個僕発明したんですけど、これ言った話ですが、ChatGPTの無料版で使ってるときとか5とかって非常に話が回りくどい。
それをいろんなシステムプロンプトというかこっちのカスタマイズで抑制しようとしてきたんですけど、話は短くしてくださいとかって。
最初の頃は聞くんですけど、なんか時間が経つと彼それを忘れるのかもしれませんか。
なんかまた泣く泣くなってきたなーっていう感じだったんですけど、あるときに一つ思いつきまして、
ユーザーの設定でパーソナライズのカスタム指示っていうのがあるんですけど、そこに回答は端的すぎるほどに端的に行う返答の短さを微徳とするとしたんですよ。
それ以降ね、圧倒的に短くなったんですけど。つまり微徳が大事なんですかね。
かなり上位に、おそらく命令の中で上位に位置づけられると思うんですけど。
それで本当に短くなったんですよ。これすごいなと思って。
行動の指示じゃなくて価値観に対応させると結構影響があるというので、これも人間的だなとちょっと思いましたね。
だから行動を指示している分には価値観は変わってないわけですね。
そうですね。だから例えばこの情報をもっと伝えなあかんっていう別の行動とマッチしたときにおそらくそっちのほうが。
そっちが優先されちゃう。なるほど。
誰より上位の規範性を設定するとかなり変わる。
常に長くないわけではないですけど、80%ぐらいはものすごく端的に返せるようになりましたね。
そのときに逆に必要なこともこなくなったみたいなことはないですか。
基本的に辞書代わりに聞くときしかチャットDBで使わないんで、話したいときはクロードさんと話すので、あんまり問題はないですね。
なるほど。
こうやって使い方はいろいろありますけど、やっぱり彼らの行動規範をいかにいい感じにするのかというのが一つの課題。
結局クロードはそれをやってるわけですけど、きっとシステムレベルでやってると思うんですけど。
人間が調整できる分やったらそうするといいですけど、これはAI倫理観的にどうなんかなという気も同時にしますけど。
勝手に美徳を決めないでくださいという感じはしますが。
でも結局、会話をするためには、実はそれがないと会話ってできないんですよね。
確かに。そりゃそうだ。
あたかも人間であるかのように会話する以上、そこは絶対にあるんですよね、きっと。
そうですね、確かに。
人間同士の会話って、胸話はしますけど、チャットGPTみたいにやたらやった話を引き延ばさないわけですよね。
それは極論に言うと、僕らが限りある人生を生きてるからなんですよね、要するに。
生命という時間の縛られがあって、その2人が共有してるからお互いに時間を使い合うという意識があるけど、
少なくともチャットGPTにはその遠慮がないというか。
そこの違いが多分影響してるとしたら、確かに倫理的な基盤の共有というのは必要なことかもしれませんね。
そうですね。
そんなとこかな。
テスト駆動式執筆が使えるのか使えないのかはわかりませんが、ある種のものの書き方とか、ある種の思考のスタイルにとって合う人がいるでしょうし、
あとテストっていう感覚を持つこと、その文章がどう機能しているのかを1回自分で考えてみることっていうのは、文章のクオリティーを上げる上では有効だと思いますね。
間違いなく有効だと思いますね。
日記とかでそこまで真剣にやる必要はないですが、やってもいいですけど、
人が読む文章とか、ある効果を期待している場合、それがたぶん削るとか削らないとか、足すとか足さへんの判断を促すと思いますね。
それがないとたぶん削り方はわからないですよね、きっとね。
やっぱり筆筆にテスト駆動を応用するっていう発想自体をやっぱり提供してくれる人がいるということは、素晴らしいことなんですよね、これがまた。
書くっていうことを書くっていう内側だけで見てたんでわからないんで、外側から見たときに書くってこういう側面あるよねっていう見方が広がっていくのはいいですね。
いや、やっぱりね、考えましたもんすごく、やっぱりそれを読んでから。
とりあえずいろいろ自分は反応があるんだけれども、いやでもそうか?みたいな、考えますよね、やっぱり。
考えます考えます。
今もだから、本当に小水泉さんが意図していたことが本当に自分が理解できているのかどうかというのも正直わからないですからね。
だから、そのわからない前提でいろいろ話してますけど、でもとにかくいろんなことを考えさせられたので良かったなと思いますね。
そういう、人間が書くことに関する話題が激減しているので、話題提供は大歓迎。絶対ね、もっと考えることあると思いますね、執筆においては。
いやー、ありますよ。
全然考えられてないところなんで、それで全然不十分なのにもう人間は書かなくていいみたいな風俗が生まれると、すごい途中で半端に終わってしまうんで、やっぱり人間が書くことを考えていきたいですね。
そこの理解がないと、生成AIを使うにしても使えないと思うんですけどね。
まあそうでしょうね。テストという関連がなかったら文章の直し方を指示もできませんからね。
いい感じに直してって言ったって、それ言われた方も困りますよね。
困って、例えば部下にいい感じに直してって言ったら、いい感じって言われたらもうちょっと具体的に指示してくださいって言ってくれるかもしれないですけど、
なんかAIが思ういい感じに直されたやつを。
でもそれを受け入れるかと思いながらみたいなところですけど、そう指示する人間がもっと端的な説明にしてくださいとか、初心者でも分かりやすいようにみたいなことが言えたらクオリティーが上がっていくわけですからね。
そうですね。
やっぱり人間の技能が生きないんじゃなくて、むしろ生きるんですよね。
持ってる技能が生成AIによってより生かされる環境になりつつあるんで、技能をみなさんせっせと磨きましょうということになりそうな気がしますが。
あとごめんなさい、もう一個だけ。70年代ぐらいの新書とか読んでると、すっごい今から見ると雑なこと書いてるのがあるんですけど、中にはすごく今は失われてしまった魅力的な文章があるんですよね。
もしかしたらそれは単なるノスタルジーなのかもしれないんですけど、別に僕70年代リアルタイムじゃないですからね。
もっと昔、自分の時代よりもっと昔ですから。
なんというか、精度が高いだけでは得られない何かというのがあるんだなと思いますね。
最近ツイッターで論文を生成AIに直させれば直させるほど魅力がなくなっていくというツイートを見たんですけど、そうなんですよね、結局。
わかる、想像つきますね。
直していくとどんどん中間になっていって、ぜひともこれを主張しなければならないコアみたいなのがどんどん薄まっていく、棘がなくなっていくというような感じだと思うんで。
別に悪文も多いですよね、昔の本で。
多いです。
読みづらいような、でも読まされてしまう何かがあるというところがあるんで。
一口で文章力といっても、きれいな文章を書ける能力だけを指すんじゃないというのは重要なことだと思いますね。
そうですね。
というところで、何かお知らせしたいこととかございますでしょうか。
今回は特に。
はい、私もございませんので。
指したドットネットを見ていただいたら、ランダムで今日の一言が表示される機能がついてるんで。
確か900個ぐらいあるんで、たぶん同じようにあることじゃないと思いますんで。
それって何か単一ファイルなんじゃない?
今日の一言が収まってるやつは1枚のJSONファイルですね。
JSONファイルか。
それを今、MDファイルにしてページにしようとしています。
なるほど、なるほど。
そういうのをどんどん自分の好きなものを集めていくサイトにしようと思ってます。
はい。
というわけで今回はこれまでにしたいと思います。お疲れ様でした。
お疲れ様でした。