ここですという名前のブログやさん

さて、この記事の趣旨はどちらかというと、雨水に雛人形を飾るという「古くからの言い伝え」は存在しないのではないか。
少なくとも、現在の暦を使わなければ、あまり実情に合わないというそういう主張であります。

まず、「雨水」といえば、二十四節気のひとつです。時々、「旧暦はいいよ、二十四節気なんかあって季節感が……」という言葉も見かけますが、本質的に二十四節気は現在の太陽暦との整合性がよくできています。
旧暦は月の満ち欠けによって日付を決めるというものですが、これだけですと、季節と暦がずれてきます。季節というのは実は、太陽の位置でもあるので、季節とのずれを補正するために、（太陽の位置をよく反映する）二十四節気を利用するというわけです。
（なので、太陰太陽暦と呼ばれます）

そういうわけなので、二十四節気の日付は、現在の暦では毎年ほぼ同じ日付になります。
たとえば、今回話題にする「雨水」は、
2010年〜2012年 ： 2/19
2013年 : 2/18
ということになります。

日付がほぼ同じ訳ですから、現在の暦でいう「３月３日」に対して、毎年ほぼ２週間前ということになります。
ですから、現在の暦では、かなり妥当性のある基準だと言えます。

一方で、これが旧暦の時代からというほど古いものであるかといえば、旧暦の日付は（現在の暦に対しては）一定しないという事実があります。
たとえば、旧暦の３月３日は、現在の暦では、
2010年 04/16
2011年 04/05
2012年 03/24
2013年 04/12
となります。
2010年などは、（現在の暦で）4/16の当日に備えて、2/19には飾り付けをするということになってしまいます。

さらにいえば、雨水に雛人形を飾るというのと併せて、啓蟄に雛人形をしまうという話もあります。
こちらは、明らかに現在の暦の産物だと言えます。
というのも、啓蟄はこれまた、現在の暦では、日付がほぼ一定しており、3/5頃です。
これまた、3/3 に節句を済ませた雛人形を（それも早めに）しまうというのには、いい目安です。

しかしです、上述の通り、旧暦の３月３日は、一番早くても（現在の暦では）３月の下旬です。
そう、啓蟄より「後」のことなのです。
もちろん、「旧暦の啓蟄は旧暦の３月３日より後」ということはありません。
啓蟄自体、「２月節」とされ、啓蟄の日は旧暦では２月にあるのですから。

EverNote の Puremium アカウントであれば、添付するファイルの種類に制限はなくなる。
そしてまた、添付されたファイルは直接編集できる。
そうなると、考え方やアイディアをまとめるために、FreeMind のファイルを添付したくなる。

が、しかし、EverNote に貼り付けた FreeMind は直接編集できない。
というわけ、これを回避する方法が見つかった。

この原意は、そもそも、FreeMind.exe を実行すると、java が立ち上がり、freemind.jar を呼び出すという流れになっているのだけれど、freemind.jar が動き始めるときには、freemind.exe は終了している。
しかも、EverNote からみみれば、.mm というファイルを生成して、freemind.exe にわたすのだけれど、freemind の実体が動き出す前に、Freemind.exe は終了している。したがって、freemind.jar が起動したときにはすでにファイルが存在していないと、そういうことなのだが。

というわけで、.mm という拡張子に、javaw.exe -Xmx256M -jar "c:\Program Files\FreeMind\lib\freemind.jar" "%1" を割り当てることで、ファイルの生成から終了まで、javaw.exe が動いているようにすれば、ＯＫということになった。

が、さらに、Windows VISTA では、（それ以降も？）この設定が直接にはできないということで、これまた試行錯誤があった。
さて、結論である。

１．c:\windows\system32 に移動して、cmd.exe を見つける（これが、コマンドプロンプトの実体）
２．右クリックして、「管理者として実行」をクリック。
３．コマンドプロンプトから、 assoc .mm=Freemind を実行。
　　（.mm という拡張子を Freemind というデータ形式と認識させる）
４．コマンドプロンプトから、 ftype Freemind=javaw.exe -Xmx256M -jar "c:\Program Files\FreeMind\lib\freemind.jar" "%1" を実行
　　（Freemind というデータ形式に対する具体的な実行プログラムを設定する、一応、 freemind.jar の場所は確認必要）

以上です。
コマンドプロンプトを管理者として実行することが必要で、たとえ、adominisitrator 権限を持っているユーザーから実行しても、コマンドプロンプトを普通に実行するだけではアウトでした。

この記事を訂正します。

この記事が最初に書かれた2011年1月の段階では、この記事は正しかったのですが、現在（2013/04/17）時点では、（かなり前から）誤っています。

EverNote のフリーアカウントで添付できるファイルが「画像とPDFのみ」という制限は現在ありません。
したがって、「編集するノート」というのは、フリーアカウントで実現可能です。

この点、訂正させていただきます。

---------------------------------------------------------------------------------

題して、「記録するノートから編集するノートへ」

冒頭に述べておけば、私自身、「もしかしたら、Microsoft One Note のほうがいいかもしれない」という思いは持ちつつ、EverNote を使っているというのはありまして、ここでも、そういう使い方を意識しています。

さて、話を元に戻せば、EverNote の Premium アカウントにおける優位点は、
・転送量の上限値が増える
・添付できるファイルの種類の制限がない
・ノートのヒストリが表示できる
という３点になっています。

このうち、最初にあげた、「転送量の上限値が増える」という点がもっともよく話題になっており、「一ヶ月の転送量が上限値を超える場合には、Premium アカウント」という認識が一般的なように思う。
ところが、使い方によっては、「添付できるファイルに制限がない」というのが、大きな意味を持ってくる。
実は、EverNote に添付されたファイルは、直接編集可能なのだ。

EverNote の通常アカウントにおける添付ファイルの制限は、よく考えられているような気がする。
画像ファイルとPDFファイル。これは、多くの人にとって「編集することのない」ファイルである。
EverNote が標榜する、「すべてを記憶する」という言葉からすれば、画像ファイルとPDFを取り扱うだけで、記憶（そして記録）が多くの場合可能である。
※もちろん、転送量の制限はあるが。

ところが、「あらゆるファイルが添付可能」かつ、「添付されたファイルが直接編集可能」ということになると、「すべてを記憶する」というノートの役割を超えて、「さらに、変化し続ける」ノートであることができる。
EverNote自身が、ノート内のテキストを変数刷る機能は持っている。
しかし、それに加えて、ノートに添付された Word やら Excel やらのファイルが直接編集可能（ダブルクリックで開いて、普通に、「上書き保存」するだけで、ノートに添付されたファイルは更新される）であることを考えると、

・ノートを作成する。
・とりあえず、メモを書き込んでおく
・なんか、必要らしいファイルを（たとえば、PowerPoint）貼り付けておく
・新たらしい情報を元に、プレゼンテーションの内容を変更する
・検討データとして、Excel を貼り付ける
・そのExcel の説明をテキストで書き込んでおく
・Excel の情報を更新する
・途中で拾った写真をヒントとして貼り付けておく
・Excel のデータをみながら、写真を貼り付けながら、プレゼンテーションを完成させる
・ついでに、入手した発表スケジュールを貼っておく

という流れが、ひとまとまりのノートの中で完結する。
こうなれば、当然、転送量は増大する（添付ファイルを更新するたびに、新たなデータを転送する必要があるから）
故に、Premium アカウントでは、転送量の上限が引き上げられる。

こういう編集をしていると、どうしても、「昨日の資料」に帰りたくなる。
故に、Premium アカウントでは、ノートのヒストリが参照可能である（昨日の資料が再現できる）
※ただ、ヒストリは、必ずしも全部のステップが残っているというわけではなさそう。

ということなのだと思う。
というわけで、すでにできてしまったものを記憶するというだけではなく、ノートを編集しながら、記録すべきものを作り上げてゆくという、そういう用途に使うことが可能になるわけです。

※ただ、少なくとも現時点では、処理をするのに複数のファイルが必要なものは、編集ができないです。
　これは、ダブルクリックの時点（または、Open または、Open with でファイルを開こうとした時点）で、ファイルの実体が生成されるためです。開こうとしたファイルだけしか、ファイルの実体としては存在していないので、複数のファイルを組み合わせて処理するようなアプリケーションだと、指定していないファイルの実体は存在しないからです。

2011年2月6日 追加分です。

樹脂材料調達成功上のため → 樹脂材料調達性向上のため
蒸す迷惑 → 娘曰く
単に施米からじゃなくて、 → 単に狭いからじゃなくて
深い足しました → 付加いたしました
当シャモですが → 当社もですが
電源ラインの出石県 → 電源ラインノイズ試験
ここで対回り込みを許可 → ここでタイマ割り込みを許可
また園は無しか → またその話か
位までもスイッチは使われている → 今でもスイッチは使われている

-------------------------- ここまで ---------------------------------------

年末も近くなりましたが、今年集めた ATOK 2010 の誤変換リストです。
以下のものは、実際に変化された結果ですが、当方の単語登録や普段どんな言葉を多用しているかで、いろいろと違いは出てくるかもしれません。

では。

佐藤△保住
　→ 佐藤さん確保済み

恋うて以外での確認
　→ 工程外での確認

実機でバッグ
　→ 実機デバッグ

テスト洋館数ファイル作成
　→ テスト用関数ファイル作成

状態だとか呈する
　→ 状態だと仮定する

ブラ施設返事の検証事項確認
　→ ブラシ設変時の検証事項確認

本社へ伸ばす
　→ 本社へのバス

年末可燃しか、そのあたりに
　→ 年末か年始か、そのあたりに

基板と利雪
　→ 基板取説

はんこ低抵抗の
　→ 半固定抵抗の

同じファイルの中野か区間数
　→ 同じファイルの中の各関数

人がいればもう獣
　→ 人がいればもうけもの

モータか変モジュール
　→ モータ可変モジュール

案外な外貨も
　→ 案外長いかも

半生コメント締め切り
　→ 反省コメント締め切り

特にして伊那市でよいと思います
　→ 特に指定なしでよいと思います

一同かがいましたがお忙しそうだったので
　→ 一度伺いましたがお忙しそうだったので

デー大切先
　→ データ移設先

どう査定し次官は
　→ 動作停止時間は

最後は案がイラクでした
　→ 最後は案外楽でした

運用の点から、まず移転があると思います
　→ 運用の点から、まずい点があると思います

Twitter の Bot 「節気さんシリーズ」で月の名前を求めるという計算をしています。
※月と言っても、天体の月です。「三日月」とか、「十五夜」とかそっちの名前。

これ、実はまじめに計算すると結構大変でして、節気さんシリーズの中でも、一番面倒な計算です。
※ただし、太陽と月の位置を決定するという基礎的な計算の方がはるかに面倒であるのはもちろんです。
※ただ、こちらのほうは、『日の出・日の入りの計算』（長沢工著，地人書館）に収録されているアルゴリズムを元にしたものなので、自分では計算していないという。

そういうわけで、宣伝の意味も込めて（ほとんどそれだけ）紹介してみることにしました。
実際の計算結果（イメージ）も最後につけました。

【ある時刻における「月の名前」を求める】

１．定義
　「月の名前」は、「ある時刻」を含む旧暦の（カレンダーの）月における月の出現回数で決定される。
　※具体的に採用している名前は後述
　この定義では、実は、「月が出ていない」時の名前が決定されないので、「節気さんシリーズ」では、
　・旧暦の１日はその日を通して、「朔月」
　・旧暦の晦日はその日を通して、「晦日月」
　・その他の日は、「日本における月の入り（実際には、登録している50地域）」が完了して、10分経過後に次の名前に変更する
　というロジックを採用しています。


２．求め方

1）「ある時刻」における「直前の朔の時刻（「ある時刻」以下）」と「直後の朔の時刻（「ある時刻」超過）」を求める
2) 「ある時刻」が、旧暦１に含まれる場合は、「朔月」とする
3）「ある時刻」が、旧暦の朔月（直後の朔の時刻を含む日の前日）なら、「晦日月」とする。

4）それ以外の場合は、計算が必要。
5）旧暦日付が基準になるので、
　「調査開始時刻」＝「直前の朔の時刻を含む日の 00:00」
　「調査終了時刻」＝「直後の朔の時刻を含む日（は、来月の１日）の前日の 23:59」とする
6）「調査開始時刻」以降の最初の「月の入り」を、50の地域について求める。
　 50の地域を比較して、最も遅いものを、「１回目の月の入り」とする。
7) 「１回目の月の入り」以降の最初の「月の入り」を、50の地域について求める。
　 これが、「２回目の月の入り」となる。
8) 以降同様にして、「月の入り時刻」が、「調査終了時刻」以降になるまで月の入り時刻を求める。
9) 以上で求めた、「n回目の月の入り時刻」に10分を加算する。これが、「n + 1回目の月の名前の開始」となる。
10) 「n回目の月の名前の開始」が、旧暦 n - 1 日であれば、その時刻を、旧暦 n - 1日の 23:59 にする。

11) 「n回目の月の名前の開始」時刻が、「ある時刻」以上となるような最初の n を求める。
12) n 番目の月の名前を、「月の名前」とする。

３．具体的な月の名前
（括弧内は、出現回数です・8, 12, 22 は名前をつけていません）

朔月(1), 既朔(2), 三日月(3), 夕月(4), 夕月(5), 宵月(6),
弓張月(7), 九夜月(9), 十日夜(10), 十日余の月(11),
十三夜(13), 小望月(14), 十五夜(15), 十六夜(16), 立待月(17),
居待月(18), 臥待月(19), 更待月(20), 二十日余の月(21),
弓張月(23), 有明月(24), 有明月(25), 二十六夜(26), 暁月(27),
暁月(28), 暁月(29), 暁月(30),

計算結果は、こんな感じになります。
月の出が少しずつ遅くなっているので、それにつれて、「月の名前」の変化点も後ろにずれています。

この記事を書いているとき、既に、2010年も年末の兆しが見え、来年のカレンダーの話題がちらほら聞かれている。
その中で、「月齢表示のあるカレンダー」というのが一定の関心を集めているようである。
ただ、この種のカレンダー、表示方法故にいくらか誤解というか、誤ったイメージを与えているのではないかと思う次第である。

手元に、2011年の月齢カレンダーがあれば、１月１日の月齢を見て欲しい。
もしも、26.4 と書かれていれば、そのカレンダーは、「正午月齢」を表示していることになる。
月齢というのは、新月の瞬間から単純に日数をカウントしたものである。ただ、１日単位だけではなく、１日で、ひとつ月齢が進むように小数点付きで表示していることが多い。
そうなると、たとえば、午前０時の月齢が、10.0 だとすると、午前６時は 10.25、正午は 10.5、午後６時が10.75。そして、翌日の午前０時が11.0となる。
このように、「今日の月齢」というのは定義できないことになる。
では、月齢カレンダーに書かれている「今日の月齢」は何かといえば、ある時刻の月齢を以てその日の月齢を代表させているわけで、多くの月齢カレンダーで、正午月齢を代表としているわけである。
このほかにも、たとえば、天文暦だと、20時や、21時の月齢で代表させているケースも多い。

これから言えるのは、月齢カレンダーに正午月齢が表示されてても、「今」の月齢はそれとは異なると言うことである。
たとえば、午後６時であれば、0.25を足せばよいし、午前６時であれば、0.25を引けばよい。

表示されているのが正午月齢だと言うことは、ちょっとおかしなイメージを与えることがある。
たとえば、2011年４月３日の月齢は、「29.3」と表示されていると思う。そして、翌４月４日は、「0.5」と表示されていると思う。
「新月」は、どちらの日付になっているだろうか？（正解は、４月３日）
月齢0.5の４月４日ではなく、月齢29.3の４月３日が新月というのは、奇妙な感じを抱かないだろうか？

実は、このときの朔（新月）の瞬間は、４月３日の23:32と、ほとんど一日の終わりになっている。
この瞬間が月齢0.0であり、確かに、４月３日が新月なのであるが、表示されている月齢が正午月齢であるため、新月から約半日経過した、４月４日の月齢が、0.5と一見新月の日の月齢に見えるわけである。

これと関連するのだが、、月齢カレンダーにはたいてい、「満月」や「新月」・「上弦」「下弦」の日付が入っている。
これも、どうも、「その日の夜に」というイメージが与えられてしまうらしい。
ところが、2011年３月20日には、午前 3:10 と言うところで、「望（満月）」を迎える。
カレンダーには、「３月20日は満月」と記されるわけだが、厳密には、前日の夕方に昇って朝６時頃に沈む月が満月の瞬間を含んでいるわけで、当日の夜に登る月は、既に満月を過ぎているということになる。
このときの満月を楽しみにして、３月20日の夜を待っていると、ちょっと外れるというわけである。

さて、このブログでは何度か、「月齢と月の形は厳密には一致しない」という旨の記事を書いてきた。
前回も、「満月の時、月齢はいくつ？」 http://asano-nagi.sblo.jp/article/40890434.html と称して、満月の時点における月齢がどの程度ばらつくかを検証したりした。

この記事を書いている近辺では、2010年11月22日の望があり、またぞろ、月齢15.0が満月の瞬間という表現を見つけたので、今度は逆に、月齢が 15.0 になった瞬間における月の様子を検証してみることにした。
例によって、検証範囲は 2000年１月１日から、2020年12月31日までの間である。

そもそも、「満月」という概念に相当するのは、２つのケースがある。
ひとつは、現在の天文学上「望」と呼ぶ瞬間であり、これは、地球から見て太陽と月が正反対になる瞬間である。
今ひとつは、いわゆる、「十五夜」であって、旧暦の15日の夜に昇る月を示している。
後者が、月齢15.0は満月という誤解の元であるのは間違いなかろう。しかし、たとえば、新月の日には（その日のうちに）月齢は０になるが、それはまた、旧暦の１日（カレンダーに０日というのはないから）であることを考えれば、月齢の数字と旧暦の日付は一致しないということが理解いただけると思う。
実際、旧暦の15日に相当する日全体における、月齢は最小で13.0 最大で14.9 であり、旧暦15日の内に月齢が15になることはあり得ないのである。
※ただ、十五夜の月というのは、翌日（旧暦の16日）の日の出頃に沈むので、十五夜の月が沈むまでの最大の月齢は、おおよそ、15.2程度まで進む可能性がある。

以上を踏まえて、検証を行った。
以下で、「満月の瞬間」としているのは、「天文学上の望」の瞬間である。

まず、輝面比を調べてみる。月の形は直接には輝面比として表されるので、どの程度満月の形から離れるかを検証するわけである。
その結果、月齢15.0時点の輝面比は、98.6% 〜 100.0% となった。
意外にも、一番欠けているときでも、1.4%しか欠けないということで、これは、少なくとも肉眼で見る限り「満月」であろう。
冷静に考えれば、満月の頃と新月の頃はいずれも輝面比の変化量が少ない時期に当たっていて、これは、当然の結果ではあった。

では、月齢が15.0の瞬間と満月の瞬間はどの程度離れているだろうか？
それをヒストグラムで表したのが下の図である。
最大では、26時間（つまり、１日以上）前に望になっていることもあれば、その後、16時間後に望になることもあるという結果が得られた。
また、グラフがマイナスのほうに偏っているのは、言い換えれば、月齢15.0になる以前に望になってしまっているケースが多いことを示している。



最後に細かなデータを示せば、月齢15.0の瞬間と望の瞬間が最も近い／遠い日は以下のようになっている。
一番近いときでも、８分ほどの差があることがわかる。

満月まで一番近いとき
2007-10-26 14:00 月齢15.0
2007-10-26 13:52 望

満月まで一番遠いとき
2011-07-16 17:54 月齢15.0
2011-07-15 15:39 望

さて、これを書いている前日（9/22）は、中秋の名月。そして、今日（9/23）が満月。
さらには、今日の月齢（正午月齢）が、14.7で、ついでに、満月なのに十六夜。

このあたりの情報が混乱している様子が見られた。
また、「満月というのは、月齢15の月のこと」という認識も割合に広まっているようで、さらに混乱に拍車をかけているようである。

このあたりは、以前、「月齢と月の呼び名」（ http://asano-nagi.sblo.jp/article/39959609.html ）や、「月に関するいくつかの指標 ―― 月齢・月相 そして、月の異名」（ http://asano-nagi.sblo.jp/article/38671358.html ）で書いてきたとおり、月齢と月の形は、きちんとした傾向があるけれど必ずしも、月齢いくつが満月と合わないということになる。

では、実際、満月の瞬間の月齢はどの程度ばらつくのだろうか。
これを、2000年から2020年の範囲でヒストグラムにしてみた。



事前の予想では、ばらつくとは言っても、ある月齢を中心とした山なりグラフが書けるだろうというところであったが実際には、中央がへこんだ凹型のグラフになった。
ちなみに、上述の範囲では、満月の瞬間の月齢は、2011/07/15 15:38 の 月齢13.9 が最小。2010/12/21 17:13 の 月齢15.6 が最大のようである。

では、なぜ、月齢の分布が山なりグラフにならなかったのだろうか？
それを確認するために作ってみたのが、次のグラフである。

これは、横軸に満月になった時刻。縦軸にその時の月齢をプロットしたものである。
21年分のデータを同じ日付でそろえ、２１本の線で傾向を表している。



これは、横軸に満月になった時刻。縦軸にその時の月齢をプロットしたものである。
21年分のデータを同じ日付でそろえ、２１本の線で傾向を表している。

このグラフから二つのことがわかる。
ひとつは、満月の時の月齢が変化する様子が、なめらかな曲線の上にあるという点。
そして、その曲線の最大部分と最小部分が、季節の影響を受けていると言うことである。
つまり、月齢の最大部分は、冬至頃のほうが大きく、夏至頃は若干小さいと言える。

月齢変化の曲線を見ると、中央部分の変化は比較的大きく、最大部分・最小部分の変化は緩やかである。
この結果、点の密度としては、最大部分や最小部分が大きくなり、これが、前述のヒストグラムで凹型のグラフになった原因である。
また、全体が凹型とは言っても、月齢17.5付近にいくつか点が存在する。
これは、月齢のもっとも大きな部分が冬至周辺の直に限定されることから、全体のグラフが凹型であるにもかかわらず、月齢の最大部分には、少数の点しか存在しないということになるのだろう。

今でも、「このコンテンツは著作権法で保護されています」という文言と、「無断引用禁止」という文言とがともに書かれている場面に出会うことがある。
しかしながら、この二つの言葉は（2010年時点の日本国内においては）両立するものではないというのが、この記事の趣旨である。

まず、「引用」という単語。
この言葉を、「部分的な転載」と解して使用していると思われる場面が多い。
実際に辞書を引いてみると、
「他人の説や文章を自分の説や文章の中に使うこと」（学研国語大辞典）
「自分の説のよりどころとして他の文章や事例または古人の語を引くこと」（広辞苑）
「自説を証明したり物事を詳しく説明したりするために、他人の文章・他の説・故事などを引いてくること」（明鏡国語辞典）
と、辞書の記載においても、単純な「部分的な転載」とは解釈されていないことがわかる。
つまりは、「引用」という言葉自体が誤解されて使われているのではないかということである。

さて、さらにいえば、著作権法には、（著作権法としての）引用も定義されている。
そして、著作権の制限のひとつとして、「引用は可能」とされているのである（32条）
著作権法における引用とは、概ね、
・自説の展開、または批判のために必須であり
・引用部分が従であり
・引用元が明示されている
という要件が必要とされている。逆に言えば、この要件を満たす引用を著作権は許しているわけである。

さて、著作権と引用の関係であるが、それを説明するためには著作権法の意図を知らなければならない。
著作権法第１条に、以下のような（目的）が定められている。
「この法律は、著作物並びに実演、レコード、放送及び有線放送に関し著作者の権利及びこれに隣接する権利を定め、これらの文化的所産の公正な利用に留意しつつ、著作者等の権利の保護を図り、もつて文化の発展に寄与することを目的とする。」

著作権法の目的は、「文化の発展に寄与する」ことであって、必ずしも著作権者の保護ではない。
文化の発展に必要だから、その手段として著作権を保護するとしているのである。
だからこそ、文化の発展を阻害する程度の著作権保護は行わない。故に、「著作権は制限される場合がある」のだ。

冒頭の「引用」は、この「著作権の制限」のひとつである。
言い換えれば、著作権法が「文化の発展に寄与する」という目的のために、「引用は認められるべき」としているのである。
だから、「引用」を禁止するということは、「引用」という言葉を正しく理解していないと表明することになるのか、あるいは、（著作権を保護して欲しいといいつつ）著作権法の理念を無視しているか、いずれにしても、正しい主張ではないということである。

さてさて、このお話は、どこにあるのかわからない、「ツイット国」のお話です。
実は、この国の人々は、かけ算は得意ですが割り算は苦手……というより、存在すら知りません。
ちょっと変な仮定ですが、物語風 OAuth の説明に必要な仮定ですので。

【はじまりはじまり】

この国に、ツイット太郎という若者がいました。
太郎は、近所のツイット亭というレストランが大のお気に入り。三度の食事をもれなくここで食べていました。
そうなると、面倒なのがお金の支払いです。
そうは言っても、太郎も悪人ではなく、単にお金を持ち歩くのが面倒なだけでした。
そこで、太郎は考えます。
そうだ、ツイット亭の人に、ツイット銀行まで行って、自分の口座から代金を引き落としてもらえば良いんだ。

そうして、太郎は、ツイット亭の人に定期的に銀行まで行くようにお願いし、ツイット亭の人も快く引き受けてくれました。

【Basic 認証の時代】

この時代では、太郎は、お店の人に２つのことを教えます。
１）口座番号（ここでは、12345678 とします）
２）暗証番号（ここでは、7777 とします）
以上です。

お店の人が銀行に行ってお金を引き出すようです。
亭：もしもし、口座番号 12345678 からお金を引き出したいのですが。
銀：では、暗証番号をどうぞ
亭：7777 です。
銀：暗証番号はあっています。では、必要なお金をどうぞ……

こういう会話が交わされます。
……危ないですね？

危ないと言っても、お店の人が太郎の食べてないもののお金まで引き落としてしまうかもしれない……というお話は、今回は、扱いません。
そもそも、そんなおかしなことをするかもしれないお店に、引き落としの代行は依頼しないだろうというのが、基本方針です。

もうひとつの危険性。
もしも、この会話を悪人が聞いたらどうなるでしょう。
早速、ここで聞き耳を立てていた悪人がいたようです。

悪：もしもし、口座番号 12345678 からお金を引き出したいのですが。
銀：では、暗証番号をどうぞ
悪：7777 です。
銀：暗証番号はあっています。では、必要なお金をどうぞ……
悪：しめしめ……。

ただ単に聞いていたことを繰り返すだけですから、簡単なことです。さらに悪いことには、銀行には、「だれがお金を下ろしたか」という記録は一切残りません。
銀行としては、正しい口座番号と暗証番号を知っていたのだから、正しいお客様だと判断するしかないのです。

【OAuth の時代】

さて、Basic 認証はあまりに危険だ……特に、お金を引き出すときの会話を盗み聞きされたどうしようもない。
そこで、時代は、OAuth の時代になりました。
ここでは、ツイット太郎は、ツイット亭と、さらに、ツイット銀行を交えて、４つの情報を決定します。
１）お店の「店舗番号」（ここでは、00110022 とします）
２）お店の「暗証番号」（ここでは、8888 とします）
※ここまでの情報は、「アプリケーションの登録」をしたときに決まります。ユーザーには直接関係ありません。（Twitter が割り当てます）
３）太郎さんの「ツイット亭専用」口座番号（ここでは、11223344 とします）
４）太郎さんの「ツイット亭専用」暗証番号（ここでは、1111とします）
※最後の２つは、「OAuth を承認」したときに決定されます。（Twitter が割り当てます）

さて、今回もお店の人が銀行に向かいお金を下ろします。

亭：店舗番号 00110022 のものですが、11223344 の口座からお金を下ろしたいのですが。
銀：では、最初に、「一回だけ番号」を適当に言ってください。
亭：じゃ、6543 にします。
銀：わかりました。では、「しぐねちゃ」をおしえてください。
亭：えっと〜
　　ここで、ツイット亭の人は、「しぐねちゃ」を計算し始めます。
　　計算方法は、
　　1) 店舗の暗証番号（8888）と、お客様の暗証番号（1111）をくっつけて、88881111 という数字にする。
　　2）それに、「一回だけ番号」の、6543 をかける
　　3) 結果は、88881111×6543=1728524313
亭：しぐねちゃは、1728524313 です。
銀：正解です。では、必要なお金をどうぞ……。

さてさて、今回も悪人が聞き耳を立ています。

悪：店舗番号 00110022 のものですが、11223344 の口座からお金を下ろしたいのですが。
銀：では、最初に、「一回だけ番号」を適当に言ってください。
悪：じゃ、6543 にします。
銀：その番号はさっき使ったのでだめです。ちゃんと、「一回だけ番号」を言ってください。
悪：困ったなぁ〜　適当に、9876 です。
銀：わかりました。では、しぐねちゃをおしえてください。
悪：しぐねちゃあれ？　暗証番号がわからないから、計算できないよ。

ということで、聞き耳をたてていても、失敗に終わるという仕掛けです。

【まとめ】

・OAuth では、暗証番号に相当するものを相手に伝えるかわりに、「それを知らなければできない計算の答」を伝える
　だから、聞き耳をたてていても、暗証番号に相当するものは奪えない。
・OAuth では、「一回だけ番号」に相当するものがあって、毎回送信する情報が変化する。
　だから、聞き耳をたてて、送信されたものを再利用することができない
　（実際には、送信する時点の時刻情報も併せて使います）
・OAuth では、ユーザー情報は、「そのお店専用」になっている。
　だから、直接誰がお金を引き出したか（誰が、ツイートしたか）がはっきり残ってしまう

こんなことをして、承認していない相手に情報が漏れ、不正に使われることを防止しているわけです。

【注意】

このお話の前提となっているのは、「ツイット国の人々は割り算ができない」ということです。
現実の世界では、88881111×6543=1728524313 という計算の答え（しぐねちゃ）と、一回だけ番号（6543）がわかっているのですから、割り算をすることで、88881111 というお店と太郎さんの暗証番号がわかってしまいます。
実際、ここの計算は、単なるかけ算ではなくもう少しややこしい計算が使われています。
ただし、このお話のように、計算するのは（コンピュータなら）簡単だけれど、答えからもとの数字を割り出すのは非常に困難という、そういう計算が使われています。

この例を含めて、技術的には、正しくない内容が含まれています。
また、「４つの情報を決定します」とだけ書いた、決め方の部分もかなり面倒なやりとりがあります。
まあ、そういう点を全部無視していますが、なぜ、OAuth のほうが Basic 認証より安全なんだ？　というイメージとしては、大きくは間違っていないと考えています。