団塊世代の黄昏

Mathjaxの設定

WordPressで手っ取り早くLatex数式を使用したい場合は、プラグイン「MathJax-LaTeX」をインストールすればよいのだが、CDNから最新版のものを使用したいような場合の設定方法について説明する。
CDNを使用する場合、新たなプラグインをインストールし、WordPressテーマのヘッダにスクリプトを設定するため、不慣れな方は「MathJax-LaTeX」を使用する方が無難と思われる。
CDNの設定手順を以下に示す。

• 1. プラグインの確認とインストール
  • WordPress管理画面の「プラグイン」>「新規追加」を開く。
  • 検索窓に「WPCode」と入力する。
  • WPCode Lite を「今すぐインストール」して「有効化」する。
• 2. ヘッダー（Header）へのコード挿入
  • 有効化すると、管理画面の左メニューに「コード スニペット」という項目が追加される。
  • 「コード スニペット」>「ヘッダーとフッター」 を選択する。
  • 画面上部にある 「ヘッダー」 のテキストエリアに、読み込ませたいMathjaxのCDNコードを貼り付ける。貼り付けるコードは例を参照
  • 画面右上にある 「変更を保存」 ボタンをクリックする。

【例】Mathjax CDN

Mathjax 記法

• インライン記法
  数式を \(…..\) で囲む When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are

  1 2 3 4 5

  数式を \(…..\) で囲む   When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are

  When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are

• ブロック記法
  数式を\[と\]で囲む

  1	数式を\[と\]で囲む

  数式を\[と\]で囲む \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}\] または \[x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\]

  1 2 3 4 5 6 7

  数式を\[と\]で囲む   \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}\] または \[x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\]

  \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}\] または
  \[x = \frac{-b \pm \sqrt{b^2 – 4ac}}{2a}\]

互換性

CDNだけをヘッダに設定した場合、過去に\$（インライン）、\$\$（ブロック）使用していた数式が変換されなくなります。
この問題を解消するためには、前段で設定した Script タグの下に、次のコードを貼り付けます。

これにより、以前のコードそのままに数式を表示させることができます。
【使用例】

$$x = \frac{-b \pm \sqrt{b^2 – 4ac}}{2a}$$

基本的には、AdSenseの「共通コード（スクリプト）」をWordPressのタグ内に1度だけ貼り付けるだけで、AIが記事内の最適な場所に広告を自動挿入するようになります。
WordPressに設定する3つの代表的な方法を紹介します。ご自身のスキルに合わせて選んでください。

---

方法1：テーマの標準機能を使う

多くのWordPressテーマ（Cocoon、SWELL、Lightningなど）には、最初からAdSenseコードを貼り付ける専用の枠が用意されています。プラグインを増やしたくない場合に最適です。

1. WordPress管理画面から [外観] ＞ [カスタマイズ]（またはテーマ固有の設定メニュー）を開く。
2. 「アクセス解析」 や 「高度な設定」、「ヘッドタグ挿入」 といった項目を探す。
3. AdSenseの管理画面からコピーした「自動広告コード」を貼り付けて保存する。

方法2：プラグインを使う（テーマに機能がない場合）

テーマ側に設定項目がない場合は、安全にコードを挿入できるプラグインを使用します。テーマを切り替えても設定が維持されるメリットがあります。

1. [プラグイン] ＞ [新規追加] で 「WPCode」 または 「Insert Headers and Footers」 を検索してインストール・有効化する。
2. 管理画面のメニューに「コードスニペット」が表示される。
3. 「ヘッダー」と書かれた入力欄に、AdSenseコードを貼り付けて保存する。

Google公式の 「Site Kit by Google」 プラインを使用すると、コードを手動でコピペする必要がありません。さらに、WordPressの管理画面内でAdSenseの収益やアクセス数（Analytics）を同時に確認できるようになります。

1. [プラグイン] ＞ [新規追加] で 「Site Kit by Google」 をインストール・有効化する。
2. 画面の指示に従って、ご自身のGoogleアカウント（AdSenseを所有しているアカウント）と連携する。
3. プラグインの設定内で「AdSense」を有効（オン）にすると、自動で最適なコードがWordPressに埋め込まれます。

---

## ⚠️ 設定後の重要な注意点

1. 広告が表示されるまで時間がかかります
設定完了後、実際に広告が表示され始めるまでに数時間〜数日かかることがあります。設定直後は「空白」になることが多いですが、エラーではないため少し時間を置いて確認してください。
2. 広告ブロックをオフにして確認する
先ほど確認したとおり、ご自身のブラウザのAdBlockが有効なままだと、正しく設定できていても広告が表示されません。確認時は「シークレットウィンドウ」を使用してください。
3. 広告が多すぎると感じた場合
自動広告の量が多すぎてブログのデザインが崩れる場合は、WordPress側ではなくAdSenseの管理画面（自動広告の設定）から、広告の掲載密度（量）を減らしたり、表示させたくない場所を除外したり調整できます。

---

作業を進めるにあたり、もし手順が分かりにくい場合は以下を教えていただけますか？

* 現在ブログで使用しているWordPressテーマの名前（例: Cocoon, SWELLなど）
* Google Analyticsなど、他のGoogleツールも一緒に管理したいか（Site Kitを導入したいか）

「旧暦2033年問題」とは、現在の旧暦（天保暦）のルールに従ってカレンダーを作ろうとすると、2033年の秋から2034年の春にかけて「旧暦の月名」が決められなくなってしまうという、カレンダー上の大問題のことです。1844年に天保暦が導入されて以来、初めて起こる事態です。

先ほど解説した「定気法」と「中気」の仕組みを踏まえると、なぜこんなことが起きるのかが分かりやすくなります。順を追って易しく解説します。

1. なぜ問題が起きるのか（原因）

前回の解説の通り、旧暦のルールでは「どの中気が入るか」で何月かを決め、中気が1つも入らない月を「閏月」とします。しかし、定気法の導入によって中気と中気の間隔が伸び縮みするようになった結果、「ひと月に中気が2つ入る月」や「中気が1つも入らない月」が不規則に発生するようになりました。

これによる混乱を防ぐため、天保暦では以下の強力な「固定ルール」を追加しました。

• 秋分（中気）を含む月は必ず「8月」とする
• 冬至（中気）を含む月は必ず「11月」とする
• （※春分は2月、夏至は5月とする）

ところが、2033年の秋から冬にかけて、中気が2つ入る月が2回、中気が1つも入らない月が3回も連続して発生するという極めて珍しい星回りになります。

すると、固定ルールによって「秋分を含む月＝8月」と「冬至を含む月＝11月」は確定するのですが、その間に「9月」と「10月」の2ヶ月分を入れなければならないのに、通常の月（中気を1つだけ含む月）が1回しかやってこないという事態が発生します。
結果として、9月と10月を当てはめることができず、旧暦のルールが完全に破綻してしまうのです。

2. どうやって解決するのか？

天保暦のルールだけでは解決できないため、どこかで妥協して独自の解釈（ルール変更）をするしかありません。専門家の間では主に以下の解決案が考えられました。

• 案1（冬至優先）：冬至を優先して当てはめる方法（これにより「閏11月」が発生する）
• 案2（秋分優先）：秋分を優先して当てはめる方法（これにより「閏7月」が発生する）
• 案3：その他の並べ方

3. 現状はどうなっているか？

現在、旧暦は公的な暦としては廃止されているため、国立天文台などの公的機関が「今年は案1でいきます」と決定することはありません。

しかし、カレンダーを作る業界では、旧暦や六曜（大安・仏滅など）が決められないとカレンダーを印刷できず大混乱になります。そこで、国立天文台のメンバーやカレンダー業界の団体が参加する「一般社団法人 日本カレンダー暦文化振興協会」が検討を行い、「案1（閏11月を置く）」を推奨するという見解を発表しました。
この見解は業界内で強い影響力を持つため、市販のカレンダーはおそらく「案1」に沿って作られることで問題が回避される見通しです。

（おまけ）中国では起こらない問題

旧暦（太陰太陽暦）を使用し、春節（旧正月）などを祝う中国ですが、この2033年問題は発生しません。中国の暦（時憲暦）は、「冬至を含む月から、次の冬至を含む月までに13ヶ月ある場合、最初の中気がない月を閏月にする」という非常にシンプルなルールを採用しているため、天保暦のように矛盾が生じないようになっています。（シンプルな平気法を採用しているからと言って、日本の定気法は複雑だから暦計算が優れていると考えるのは誤りです。時憲暦（清朝）以前の暦では定気法が採用されていたからです。天保暦のような問題が発生することを予見して、単純な平気法を採用したと見ることができます。）

具体的な数字を使った再説明

言葉だけでの説明では分かりにいので、表を使用し2033年の旧暦カレンダーがどのようになるかを改めて「旧暦2033年問題」を考えてみたいと思います。
以下は、資料に記載されている2033年秋から2034年春にかけての、新月（朔）と中気の配置、および想定される解決案の表です。

朔（新月の始まり）	含まれる中気	旧暦月（案1：推奨案）	旧暦月（案2）	旧暦月（案3）
2033/07/26	処暑 ( 8/23)	7月	7月	7月
2033/08/25	（中気なし）	8月	閏7月	8月
2033/09/23	秋分 ( 9/23)	9月	8月	9月
2033/10/23	霜降 (10/23)	10月	9月	10月
2033/11/22	小雪 (11/22), 冬至 (12/21)	11月	10月	11月
2033/12/22	（中気なし）	閏11月	11月	12月
2034/01/20	大寒 ( 1/20), 雨水 ( 2/18)	12月	12月	1月
2034/02/19	（中気なし）	1月	1月	閏1月
2034/03/20	春分 ( 3/20)	2月	2月	2月

なぜルールが破綻するのか？

旧暦（天保暦）の月名を決める基本ルールには、以下の強力な固定ルールが存在します。
「秋分」を含む月は必ず8月にする
「冬至」を含む月は必ず11月にする （※春分は2月、夏至は5月）
表の「含まれる中気」の列に注目してください。2033年の秋から冬にかけて、通常ではありえない星回りが発生します。
9月23日の新月から始まる月には「秋分」が含まれます。ルールに従えば、ここは「8月」にしなければなりません。
11月22日の新月から始まる月には「冬至」が含まれます。ルールに従えば、ここは「11月」にしなければなりません。
しかし、「8月（9/23〜）」と「11月（11/22〜）」の間には、10月23日からの1ヶ月分しかありません。間には「9月」と「10月」の2ヶ月分を入れなければならないのに、月が1つ足りないという決定的な矛盾が生じてしまうのです。
さらに、この時期には「中気が全くない月」が3回、「中気が2つもある月」が2回も密集して発生しているため、通常のように「中気のない月を閏月にする」という法則を当てはめることもできません。
どのように解決するのか？
「秋分＝8月」と「冬至＝11月」という両方の条件を同時に満たすことは不可能なため、どちらかのルールを妥協するしかありません。
案1（冬至優先）：「冬至を含む月＝11月」というルールを優先し、そこから遡って10月、9月、8月と当てはめる方法です。この場合、秋分のルールは妥協することになり、12/22〜が「閏11月」になります。
案2（秋分優先）：「秋分を含む月＝8月」というルールを優先して月名を当てはめる方法です。
この場合は8/25〜が「閏7月」になります
。
現在、カレンダー業界や国立天文台のメンバーなどで構成される「日本カレンダー暦文化振興協会」では、中国などの古い暦法でも冬至を定めることが暦の出発点であったことなどを踏まえ、「案1（冬至優先）」を推奨するという見解を出しています。

二十四節気の定め方には、大きく分けて「平気法（へいきほう）」と「定気法（ていきほう）」の2つの方式があります。この違いは、旧暦（太陰太陽暦）の閏月の置き方や暦の構造に大きな影響を与えました。

1. 平気法（恒気法／常気法）

平気法は、1年（約365.24日）という「時間」を単純に24等分して二十四節気を定める方法です。日本では江戸時代の天保暦より前の暦法で用いられていました。

1. 特徴: 各節気の間隔は常に一定で、中気と中気の間隔は1年÷12 ≒ 約30.4日となります。
2. 旧暦との関係: 月の満ち欠けの周期（1朔望月）はおよそ29.3〜29.8日の間で変化しますが、平気法の中気の間隔（約30.4日）の方が必ず長くなります。そのため、基本的には各月に中気が1個ずつ入り、「中気が1つも入らない月を閏月にする」というシンプルなルールで、暦と季節のズレを破綻なく調整することができました。

2. 定気法（実気法）

定気法は、天文学的な太陽の通り道（黄道）を基準とし、太陽の視黄経が15度の倍数になる瞬間ごとに二十四節気を定める方法です。日本では江戸時代末期の天保暦（1844年〜）から導入され、現在カレンダーなどで目にする二十四節気もこの定気法に基づいています。

1. 特徴: 太陽の視黄経を15度ずつ進むのにかかる時間は、季節によって変化します。これは、地球が太陽の周りをきれいな円ではなく楕円軌道で回っており、太陽に近づく冬（近日点付近）は公転速度が速く、遠ざかる夏（遠日点付近）は遅くなるためです。
2. 中気間隔の変動: この公転速度の遅速により、中気と中気の間隔も均等ではなくなり、冬は約29.5日と短く、夏は約31.5日と長くなります。

定気法の導入による旧暦の複雑化

季節の実際の変化に忠実な定気法ですが、太陰太陽暦のシステムに組み込むと厄介な問題を引き起こしました。

冬場は中気と中気の間隔（約29.5日）が、月の満ち欠けの周期（1朔望月）よりも短くなることが発生します。すると、「ひと月の間に中気が2回も訪れる月」や、逆に「本来は閏月を置くタイミングではないのに、中気が1つも入らない月」が出現してしまう可能性が出てきたのです。

これにより、「中気を含まない月を閏月にする」という従来のシンプルな原則だけでは、旧暦の月名が決められなくなる事態が生じました。
そこで天保暦では、二至二分（春分・夏至・秋分・冬至）を特定の月に固定する、以下のような強制的なルールを追加しました。

1. 冬至を含む月は必ず「11月」とする
2. 春分を含む月は必ず「2月」とする
3. 夏至を含む月は必ず「5月」とする
4. 秋分を含む月は必ず「8月」とする
天保暦を作成した人々は、より天文学的に正確な「定気法」を導入した結果、旧暦のルールを非常に複雑なものにしてしまいました。実は、この定気法と複雑なルールによって引き起こされる矛盾が、将来の旧暦の月名が決められなくなる「旧暦2033年問題」の根本的な原因となっています。

1. 二十四節気と太陽黄経との関連

二十四節気は、地球から見た太陽の通り道である「黄道」を基準に定められます。天文学的には、春分点（太陽が真東から昇り真西に沈む点）を「太陽黄経0度」とし、黄道を15度ずつ24等分して各区切りに季節を表す名称を付けたものです
。 これにより、春夏秋冬の4つの季節がそれぞれ6つに細分化されます。現在用いられている黄経15度ごとに区切る方式は「定気法」と呼ばれ、日本では江戸時代末期の天保暦から採用されました。太陽の実際の運行に基づいているため、季節感とよく一致するのが特徴です
。

2. 「中気」と「節気」の分類

二十四等分された節気は、さらに「中気（ちゅうき）」と「節気（せっき、正節とも）」の2種類に交互に分類されます。
中気: 太陽黄経が30度の倍数（0度, 30度, 60度…）になる日です。春分（0度）、穀雨（30度）、夏至（90度）、秋分（180度）、冬至（270度）などがこれにあたります。
節気: 中気と中気の中間である、太陽黄経が15度, 45度, 75度…になる日です。清明（15度）、立夏（45度）、立秋（135度）、立冬（225度）、立春（315度）などがこれにあたります。

3. 太陰太陽暦（旧暦）の月と「中気」との関連

太陰太陽暦（旧暦）は、月の満ち欠けの周期（新月から次の新月まで＝約29.5日）を1ヶ月の基準とします。
しかしこれを12ヶ月繰り返すと1年は約354日となり、太陽の動きで決まる実際の季節（1年約365日）に対して毎年約11日ずつ短くなってしまいます。 このズレを補正し、暦と季節を同期させるために用いられるのが二十四節気の「中気」です。
月名の決定: 旧暦では「どの中気が含まれるか」によってその月の名前（何月か）が決まります。例えば、「雨水（うすい）」が含まれる月を1月、「春分」が含まれる月を2月、「冬至」が含まれる月を11月とするなど、旧暦の月名の命名権は中気が握っています。
閏月の決定（無中置閏法）: 月の満ち欠けの周期（約29.5日）に対し、中気から次の中気までの間隔（約30.4日）の方が長いため、ごく稀に「中気を1つも含まない月」が発生します。旧暦では原則として、この中気を含まない月を「閏月（うるうづき）」として扱い、前月の名前を引き継いで「閏○月」と呼びます。
このように約3年に1度の割合で1年を13ヶ月にすることで、季節とのズレを調整していました。

4. 「節切り」における「節気」の役割

旧暦の月が「中気」で決まる一方で、中気と交互にやってくる「節気」は、九星気学や四柱推命などの占術・暦注において、年や月を区切る**「節切り（せつぎり）」**の基準として用いられます。
日常のカレンダーでは1日（ついたち）から月末までを1ヶ月としますが、節切りでは、太陽黄経が特定の角度（節気）に達した入節時刻をもって新しい年や月が始まるとみなします。
年の始まり: 1月1日や旧暦の元日ではなく、太陽黄経315度に達する「立春」の瞬間をもって年が切り替わります。
月の始まり: 毎月1日ではなく、各月の「節気」の瞬間で月が切り替わります。例えば、2月の始まりは「啓蟄（けいちつ・黄経345度）」、3月の始まりは「清明（せいめい・黄経15度）」、4月の始まりは「立夏（りっか・黄経45度）」となります。
このように、二十四節気は単なる季節の目安にとどまらず、旧暦における月名と閏月を決定するための「中気」システムと、気学などの占術において年・月を区分するための「節気（節切り）」システムという、暦を支える2つの重要な数理的役割を同時に果たしています。

jsonデータを生成する時には、確認し易くするため上記の方法で整形しているのだが、今回は何故かJSON_PRETTY_PRINTが有効にならず、一行の長～いテキストとして出力されてしまうのです。
オンライン json validator でチェックしても、フォーマットとしては全く問題がないにも拘わらず整形してくれないように見えます。
なぜか？
ググってみると回答がありました。
以下の通りにせよと。

‘Content-type: Application/JSON’ がないと、ブラウザにより’Content-type: Application/HTML’ と解釈されてしまい、1行の長～いテキストとして表示されるの原因だそうです。

とあるデータを入手したのだが、それには名称としてカナ名しか設定されていないので、次のような漢字名をDB（SQLite3）に追加するだけの単純なDB更新プログラムを作成してみた。

しかし、処理は正常に終了するものの、DBは更新されないのである。
原因不明なまま、悩まされること約1日。
漸くわかった、その原因。

bindParam の指定順番

 

の部分を

とすることで、更新が正常に行われるようになった。
何とも解せないのは、プレースホルダに “?” を使った次のような場合、

その指定順序は出現順に nameKanji、rkey としなければならないのは当然としても、名前（:name）を用いた場合は順序には関係なく指定できると考えていたのだが、どうもそうではないらということだ。

PDO のバグのような気はするのだが。。。私の PHP のバージョンが 7.2 と古いのでその所為かもしれないし、V8.0 以降はそんなバグっぽい現象はとっくに解消しているのかもしれないので、これ以上とやかく言うのはやめ現行の仕様に則り使って行くしかないでしょうな（くっ）。

それにしても無駄な時間を費やしたものだ。とほほ・・・

やまがた百名山

最近、youtube を見る機会が増えてきたが、中でも故郷山形の酷道・険道と称した動画が面白い。
車に積んだカメラで撮影しただけの動画ではあるが、故郷とは言え全く見たくことのない道路沿いの風景を見るのは楽しいものである。
特に、道路沿いの山々に興味を覚える。綺麗なオムスビ型の山や、奇妙な形の山、岩が露出した山などなど。
これを見ると、つい Google Map で位置を特定し、地理院地図でその山の名前を調べてしまうのである。

そのようなことを暫く行っていると、「やまがた百名山」というものがあることが分かってきた。どんな山が百名山に指定されているのかそのリストが欲しかったのだが、残念ながら「やまがた山」から一つ一つ調べるしかないらしい。
どうしても一覧表が欲しかったので、自分で作ったのが「やまがた百名山一覧」で、その位置を Google Map に示したのが「やまがた百名山の位置」である。
この百名山は、県内の山全体から登山家とか登山愛好者が厳選したものではなく、山形県を村山、最上、置賜、庄内の4地域に分け、その中から地元住民に親しまれている山を100座選んだものらしい。そのためか、鳥海、飯豊のような2000m を超える山もあれば、柏木山（飛島、58m）のような果たしてこれが山かと疑いたくなるようなものまで含まれている。しかし、国内には標高3mの山（日和山、宮城県仙台市）があって、人々がそれを「山」と呼べば高さに関係なく山になるらしいので、56mもありその地域で山と呼んでいればもう立派な山なのだろう。
生まれ育った寒河江市からは、1座のみ葉山（村山葉山、1462m）がエントリされている。身近に慣れ親しんできた長岡山（160m）、高瀬山（123m）は選外。名山かどうかはさておき、一番の思い出になる山なので一覧には、「番外」として記載しておくことにした。

DataTables

「やまがた百名山一覧」を作成する過程において、前回のブログで述べた「日本の主な山岳」も山名（漢字）と山名（かな）にそれぞれ地理院地と Google Map にリンクを張った「日本の主な山岳一覧」を作成した。
データ件数が1000件を超えると、さすがにこのままでは扱い難い。
Excelのようなフィルタリング機能、例えば、山形県のみを表示できるような機能を実現できるライブラリがないか探ってみた次第である。
そこで探し当てたのがこの「DataTables」で、HTMLテーブルに様々な機能を設定するjQuery ライブラリである。
これを使用すると、先程の「日本の主な山岳一覧」がどのように変化するかこちらを見て戴きたい。ちょっとプロっぽい体裁になっていると思う。
テーブル右上に「検索」という入力ボックスが配置されているが、ここに、例えば「山形県」とすると山形県を含むデータだけに絞ることができるので、フィルタリングとして使うことのできるものである。さらに、1ページ当たりの表示件数変更や、列ごとに昇順（▲）・降順（▼）に並べ替えることなども可能である。
この DataTables の機能については、DataTablesのサイトに詳細な説明があるのでそちらを参考に願いたい。
以上

1990年代の後半だったろうか、インターネットも普及し、Yahooなどのサイトで地図を表示できた。
不慣れな場所への出張する場合など、駅からのルートを調べるのに良く使用したものだ。
当時の地図は現在のものとは異なり、書籍の「区分地図」のようなもので、ある場所から上下左右、斜め方向にページ単位でしか移動できないものであった。
これで困るのは、地図の周辺部分の地域を調べるような場合、上に移動したり、右に移動したり、元の位置に戻したり、現在よりは遥かに低速な回線のもとページを行ったり来たりしなければならないことにあった。「この地点を地図中央にできたらなぁ」と何度思ったことか。

そこに登場したのが Google マップであった。
調べたい地点を中央に配置することも、目的地までのルートをドラッグすることでどこまでも辿って行ける、夢のような地図であった。
これにより、かつてのYahoo地図のような紙芝居型地図は淘汰され、Google Map 型の地図に置き変わり現在に至っている。

Google Map には文句の言いようがないくらい満足しているのだが、唯一不満な点は、「山」に関する情報が欠落している点だ。
富士山や蔵王山など名だたる山の位置は地図上に記載されているものの、本当に知りたい標高の記載がないのである。
これは、登山家でも愛好家でもないのに、標高だけは知りたいという個人の単なる嗜好によるものである。

そこで、無いものは無いと諦め、自分で作ってしまうことを考えた。
必要なデータは「山名とその位置、標高」であるが、幸に、国土地理院の「日本の主な山岳一覧」に1060程の山がリストされている。
（後日、やまがた百名山を「日本の主な山岳一覧」と照合したところマッチしたものは10件程だったので、実際の山の数は10,000を超えるのかもしれない。）
これを基に作ったのが「山情報の表示」である。デフォルトの表示位置が山形県になっているのは、「山」に因んでそうしたのではなく、単に私の生まれ故郷の山形県に対する郷土愛によるものであることを敢て申し上げておく。