  |
はてなキーワード:ドメインとは
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）:Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）:Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml"title="RSS"href="/feed.xml">
<meta property="og:title" content="あなたの名前 |ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home /About /Posts</nav>
<footer>© 2025あなたの名前</footer>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 734 | 松尾豊 ｜論文の書き方（英語） | ymatsuo.com |
| 648 | 結果発表 ｜次にくるマンガ大賞 2025 | tsugimanga.jp |
| 610 | オンライン署名 ·脚本家吉田恵里香氏のアニメ「ぼっち・ざ・ろっく」第二期からの脚本降板と第一期クレジットからの除名、そして原作者への謝罪を求めます -日本 ·Change.org | www.change.org |
| 590 | メモ - 男のほうがばらつきが大きく頂点も高ければ谷も深い、その生理的メカニズム | crossacross.org |
| 398 | 国内1000件の事例や製品を収録した「生成AI活用事例データベース」を公開─生成AI活用普及協会 ｜IT Leaders | it.impress.co.jp |
| 370 | NHKONE 認証コードが届かない不具合について ｜ お知らせ | www.web.nhk |
| 346 | SESで150万件のメールを送るまで | ses150-luv1p38.gamma.site |
| 339 | 精神科の入院、強度行動障害は対象外 厚労省「訪問看護で対応」｜福祉新聞 | fukushishimbun.com |
| 331 | 最近の人類のレビュー疲れ ｜ Democratizing Data | chezo.uno |
| 325 | ソフトウェアエンジニアがプロダクトにオーナーシップを持てないアンチパターン、構造 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く | nekogata.hatenablog.com |
| 320 | Windows UpdateでSSDが本当に壊れるか検証【KB5063878再現実験】 ｜ ちもろぐ | chimolog.co |
| 315 | エンジニアならtmuxくらい使いこなしたらどうだ | sititou70.github.io |
| 310 | 【彬子女王のモダン建築めぐり】東京都庭園美術館 | casabrutus.com |
| 303 | 少子化がマズいと思うなら、このくらいやろうよ -経済を良くするって、どうすれば | keizai-dousureba.hatenablog.jp |
| 303 | 今度こそ『ガリア戦記』で挫折しないための6つのコツ -明晰夢工房 | saavedra.hatenablog.com |
| 300 | ドイツの絶望 「人手不足」地獄ーー極右伸長で自滅する産業大国 ｜スマートニュース＋ | plus.smartnews.com |
| 299 | GoogleのAI要約でクリック率ほぼ半減──私たちは思考停止し始めているのか？ ｜AMP[アンプ] -ビジネスインスピレーションメディア | ampmedia.jp |
| 298 | 【速報】村井宮城県知事 “土葬”を白紙撤回 県議会で表明 ｜khb東日本放送 | www.khb-tv.co.jp |
| 288 | 経済を良くするって、どうすれば -経済を良くするって、どうすれば | keizai-dousureba.hatenablog.jp |
| 287 | 私は西鉄ライオンズに在籍したのか？ 米国からの問い合わせ 1963年の「幻」の西鉄外国人左腕を追って【全4回－①】：「おっ！」でつながる地元密着のスポーツ応援メディア西スポWEB OTTO! | nishispo.nishinippon.co.jp |
| 264 | 2020年代前半の「戦記ラノベ」についてオススメなどを語る - WINDBIRD::ライトノベルブログ | kazenotori.hatenablog.com |
| 260 | 笠井スイさんと、旅の仲間たち | geselleestelle.blogspot.com |
| 253 | 造幣局 :ドラゴンボール40周年記念2025プルーフ貨幣セットの通信販売について（2025年9月4日） | www.mint.go.jp |
| 245 | Issue, Pull-request,GitHub Copilotによる「普通」の一人チーム開発 -Cybozu InsideOut ｜サイボウズエンジニアのブログ | blog.cybozu.io |
| 244 | 任天堂がボクセルを使ったアクションゲームの特許を大量に出願していました - naoya2kの日記 | naoya2k.hatenablog.com |
| 241 | 「人間ドック」がどのように人間を破壊していくのか。何一つとして医学的ではない見地から、知られざる実態を暴きたい - もはや日記とかそういう次元ではない | manato-kumagai.hatenablog.jp |
| 240 | 英国生まれのSF作品 | www.news-digest.co.uk |
| 237 | 会話の目的は勝つことではない - ともにかける | paper2.hatenablog.com |
| 229 | 「RECORDCLUB」という海外の音楽SNSがなかなか楽しい。 -世界のねじを巻くブログ | www.nejimakiblog.com |
| 225 | この文字詰め、どっちが正解？文字間調整（カーニング）のセンスを磨いておこう | www.adobe.com |
はてなブログ10年目のkonifar-zatsu.hatenadiary.jpが7本ランクインと気を吐いている。去年の秋もホットエントリを連発していた。Kyashの役員さんとのこと。
7年目のnou-yunyun.hatenablog.comも5本と先月から好調。政治系のブログ。
| 2025年9月 | 人気エントリー入り回数 |
|---|---|
| togetter.com | 277(18.8%) |
| anond.hatelabo.jp | 178(12.1%) |
| posfie.com | 78(5.3%) |
| note.com | 58(3.9%) |
| www3.nhk.or.jp | 52(3.5%) |
| www.asahi.com | 35(2.4%) |
| www.itmedia.co.jp | 33(2.2%) |
| news.yahoo.co.jp | 33(2.2%) |
| mainichi.jp | 29(2.0%) |
| zenn.dev | 28(1.9%) |
| www.yomiuri.co.jp | 25(1.7%) |
| www.nikkei.com | 25(1.7%) |
| www.47news.jp | 23(1.6%) |
| speakerdeck.com | 22(1.5%) |
| www.sankei.com | 19(1.3%) |
| www.cnn.co.jp | 19(1.3%) |
| gigazine.net | 19(1.3%) |
| www.afpbb.com | 15(1.0%) |
| automaton-media.com | 13(0.9%) |
| dailyportalz.jp | 12(0.8%) |
| qiita.com | 11(0.7%) |
| pc.watch.impress.co.jp | 9(0.6%) |
| natgeo.nikkeibp.co.jp | 8(0.5%) |
| jp.reuters.com | 8(0.5%) |
| www.gizmodo.jp | 7(0.5%) |
| konifar-zatsu.hatenadiary.jp | 7(0.5%) |
| internet.watch.impress.co.jp | 7(0.5%) |
| blog.tinect.jp | 7(0.5%) |
| www.bloomberg.co.jp | 6(0.4%) |
| shonenjumpplus.com | 6(0.4%) |
| news.jp | 6(0.4%) |
| ascii.jp | 6(0.4%) |
| www.youtube.com | 5(0.3%) |
| www.tokyo-np.co.jp | 5(0.3%) |
| www.lifehacker.jp | 5(0.3%) |
| www.bbc.com | 5(0.3%) |
| toyokeizai.net | 5(0.3%) |
| nou-yunyun.hatenablog.com | 5(0.3%) |
| newsdig.tbs.co.jp | 5(0.3%) |
| news.denfaminicogamer.jp | 5(0.3%) |
| bunshun.jp | 5(0.3%) |
| bookplus.nikkei.com | 5(0.3%) |
| www.watch.impress.co.jp | 4(0.3%) |
| www.publickey1.jp | 4(0.3%) |
| www.jiji.com | 4(0.3%) |
| www.gamespark.jp | 4(0.3%) |
| www.famitsu.com | 4(0.3%) |
| tonarinoyj.jp | 4(0.3%) |
| news.ntv.co.jp | 4(0.3%) |
| nazology.kusuguru.co.jp | 4(0.3%) |
| levtech.jp | 4(0.3%) |
| kyoko-np.net | 4(0.3%) |
| jisin.jp | 4(0.3%) |
| econ101.jp | 4(0.3%) |
| b.hatena.ne.jp | 4(0.3%) |
郵便受けに突っ込まれてた国勢調査。「回答は義務」の表記からして気持ち悪いんだけど、氏名やら勤務先、年収など超超個人情報を、「義務」って書いてあるからホイホイインターネットで入力しちゃうのっていいんだろうか。
その紙切れが本物かどうかの確認は、多分入力先のドメインが「go.jp」でしかわからないのよ。まだ国勢調査員が手渡ししてりゃ良いけど、それでもそいつが本物かの確認は謎のIDカードで、もちろんそいつが本物かは確認しようがないわけ。
郵送すりゃ良いじゃんって話だけど、そういう話じゃなくてこの規模の、この内容の調査をこの方式でやっちまったのは、絶対将来悪用する奴が出てくると思うんだよなー。
職業プログラマになって分かったことは、職業倫理なんてものは "人が死なない限り存在しない" というものだ。
僕らを取り巻くテーゼは、 "プログラムを事前に設計して考えて書くのはバカだ" というもの。
これは、インターネット環境で修正が用意になった結果として、「その場しのぎをすればいい」という場当たり的主義が起きた。
結局のところ、そんな対応をコンシューマも許容せざる得ないのだ。そんなテーマで書いてみる。
アジャイルだとかXPという方法論の理想は認めるし、とても共感する。顧客がソフトウェア開発のプロなら成り立つだろう。
だが、実際の運用はどうだろう。顧客に未完成品を準委任で売りつけて、保守で金をせびる方便になってしまった。
XP という主張も、アジャイルという運動も、未完成品を売りつけるための手法として使われている。
いざとなったら、可能な限り修正はしますよ、という触れ込みで。僕らが頑張ってこれだったんですといえば、故意ではないのだ。
だったら、自分たちのレベルを低くした方が、免責される幅も広がるし、安く人を調達できるし、うれしいことだらけ。わらっちゃうぜ。
TDDという手法がもてはやされたりするのも、やったもん勝ちみたいな精神性があるからなのだ。
そもそもの問題として、本当のテストの設計をするには、プログラムがどのような動作をすべきか考えなくてはならない。
V&Vの妥当性確認をするには、そもそも何をしたいかわかってなくてはならないし、そのためには、上流の設計は必要だ。
そのことを考えるに、TDD を設計しつつ行うことは、上流から下流までの見識を持って行わないといけないはずだ。
しかし、テストファーストといってる人たちは、このことを矮小化して、あらかじめ自分のわかってる範囲でテストを書いておけば問題ないと言っている。
現場で始めるTDDなんていうのは、そんなもんで、そういう場当たり的なことをを持てはやしているわけで、知れたもんだよね。
こいつらバカじゃねーのか、テスト書いてれば、見当違いのことしてもいいって言ってんのかよ、って思うわけだわな。
でも、何やっても、やってよかったと心底思える人達ばかりで、住む世界がちがうわけで。かなりお花畑な人達ばかりなのよ。残念なことに。
そもそもドメインモデリングなんて、いくらでも昔に提唱されていたのに、DDDに含めるのが間違ってるのだ。
そもそも、DDDの本はドメインモデリングについて、あまり語ってないし...。
どうせ、ユースケース層というものをドメインに入れて四苦八苦してるような輩には、なんもわかるまい。
ドメインとドメインがどう使われるかは、そもそも関係にないし、関係あったら問題だろう。
でも、ユースケースをドメイン内に表現したいとかいうのが後を立たないのは、なんもわかってないからだろうな。
わかってないならわかってないで黙っていてくれともうけど、DDDやってみましたっていうよくわからない記事ばかり出てくるし...
お前らコンサルがキラキラした目で語る「SDV化へのロードマップ」ってやつ、まあ綺麗だよな。「レベル1から始まって、ドメイン、ゾーン、最後は夢のセントラルコンピュータへ！」って、すごろくみたいで分かりやすい。プレゼン資料は美しいし、ロジックも通っているように見える。
だが最近、その綺麗なすごろくを見ていると、強烈なデジャブを感じるんだ。
ついこの間までヨーロッパ中が大合唱していた、「未来はEV一択だ！」という、あの狂騒曲にな。
ご存知の通り、その結果は今のEV失速と戦略の迷走だ。今日は、なぜ俺がお前らの語るSDVに、あの失敗したEV戦略と同じ匂いを感じるのか。そして、そのロードマップに隠された巨大な「崖」について、具体的かつ論理的に話そう。
まず前提として、EUのEV戦略は単なる技術選択の失敗じゃない。あれは、「"言葉"を定義することで現実を支配しようとする」という、ヨーロッパ伝統のイデオロギー戦略だ。「EVは善、エンジンは悪」というシンプルな二元論を作り出し、規制と補助金で市場を無理やりそちらに誘導しようとした。
この手法のキモは、現実の複雑さを無視し、自分たちに都合のいい単一のシナリオを唯一の「正解」として提示することにある。世界には多様なエネルギー事情があり、多様な顧客ニーズがあるという現実から目を背け、「EV」という言葉の神輿を担いだわけだ。
そして、お前らが語る「SDV」も、これと全く同じ構造を持っている。
「セントラルコンピュータによる、ハードとソフトが完全分離したSDV」こそが唯一絶対のゴールだと定義し、そこに至る道を一本道で描いてみせる。
だが現実はどうだ？ 安くて頑丈なクルマを求める市場もあれば、運転の楽しさを求める層もいる。そもそもソフトウェアのアップデートに価値を感じない顧客だっている。トヨタが声高に未来を語らず、EV、HV、水素、合成燃料と、あらゆる可能性に備える「マルチパスウェイ」を貫いているのはなぜか。それは彼らがイデオロギーではなく、複雑な「現実」と向き合っているからに他ならない。
お前らのSDVロードマップは、この時点でまず、現実の多様性を無視したイデオロギー的な欺瞞をはらんでいる。
その上で、仮にその単一シナリオ（理想のSDV）が正しいとして、なぜその実現が絶望的に困難なのかを説明しよう。ここで登場するのが、お前らも知ってる「コンウェイの法則」だ。
雑に言えば「システムの構造は、それを作る組織の構造とそっくりになる」という法則だ。今のクルマは、無数のECU（小さいコンピュータ）が複雑に絡み合った「分散型アーキテクチャ」だ。これは偶然そうなったわけじゃない。エンジンはA社、ブレーキはB社、ライトはC社と、各分野の専門サプライヤー（Tier1）が、ハードとソフトを一体ですり合わせて開発してきた。このクルマの構造は、日本の自動車産業が100年かけて作り上げてきた、この巨大なサプライチェーンという人間関係そのものなんだよ。
そして、この巨大な人間関係の構造は、組織と同じで少しずつしか変えられない。「連続的」な変化しか受け付けないんだ。一気に変えようとすれば、現場は崩壊し、これまで培ってきた価値は失われる。
この2つの法則を踏まえて、お前らのロードマップを評価しよう。
これはまだいい。既存のサプライヤーとの人間関係を維持したまま、ECUをいくつか統合し、役割を再編成する。「組織改編」レベルの話だ。現場は筋肉痛になるだろうが、これはまだ「連続的な変化」だ。実行可能性はある。
これは「組織改編」じゃない。「全従業員を一度解雇して、明日から全く別の人種と会社をゼロから作れ」と言っているに等しい。
なぜなら、クルマの作り方が「ハードウェア部品のすり合わせ」から「OS上のソフトウェア開発」へと、根本的に変わるからだ。これは、これまでパートナーだったハード中心のTier1の価値をほぼゼロにし、NVIDIAやGoogle、AWSといった、全く文化の違うITジャイアントと新しい関係をゼロから構築することを意味する。
この「崖」を飛び越えるという行為は、必然的に「大規模リストラ」を意味する。そして、そのリストラは、これまで俺たちがサプライヤーと共に築き上げてきた無形の資産、つまり「車載特有の品質ノウハウ」や「フェイルセーフの思想」といった、カネでは買えない価値（バリュー）を崖の下に投げ捨てる行為に他ならない。
俺たちの議論は、お前らの美しいパワポの上にはない。この血と汗にまみれた現実にある。
だから、お前らが本当に俺たちのパートナーだと言うのなら、答えるべき問いはこれだ。
この「崖」を越えることで失われる、既存サプライチェーンの無形資産（品質ノウハウ、信頼関係、暗黙知）は、金額換算でいくらだ？その減損を、どうやって、何で補填する計画なんだ？
「意識改革」みたいな精神論で逃げるな。どのTier1との関係をどう縮小・終了し、どのITベンダーと、どのような契約・開発体制で、何年かけて新しいエコシステムを構築するのか。その移行期間中のリスクとコスト（訴訟リスクや技術者流出を含む）を算出して見せろ。
この無謀なジャンプの途中で、開発が頓挫したり、大規模リコールが発生したりした場合、会社をどう守るんだ？そのための具体的な資金計画と、リスクヘッジのシナリオを提示しろ。
これらの問いに、具体的かつ定量的に答えられないのであれば、お前らの提案は、現場の現実を無視した無責任な空論であり、俺たちを崖から突き落とそうとする悪意の塊だ。
俺たちは、崖の向こうの楽園の絵が見たいんじゃない。
今時のWebサービス提供者で、「UI/UXに力を入れています」と表明していないところはないだろう。
でも実際は？ っていうと、必要な処理要件を書き出して、要素を画面に並べて、ちょっとビジュアル的に今風にしてるだけ。
それで「UI/UXに力を入れています」とか、ちゃんちゃらおかしい。
転職サイトを使って見ているのだが、使いづらい。
これが要件だ。
どうなっているか？
企業Aには何日の何時から何時まで、企業Bには何日の何時から何時まで、企業Cには……。
それを元に担当者が連絡とって……。
違う 違う そうじゃ そうじゃない
企業との面談スケジュールだけど、管理すべきはそれぞれの登場人物の空き時間という排他的リソースなんだよ。
だから、求職者(と転職企業の担当者)の空き時間の重なった部分を企業の担当者に提示して予約枠を確保してもらう。
ってのが正しい機能のあり方なんだよ。
企業側で複数人が立ち会う必要があるなら、企業側からの予約枠確保時に参照できるようにしておく。
なのになんでこうなった？
こいつは機能デザインとドメイン駆動開発の大事な考え方でもある。
こんなもん、三秒で考えつけ。
そういうもんなのである。
正直、AI に命令を出すリード、マネージャ、リーダーの能力が上がらないと、AI でコードを大量生産すると手に負えないスラムが根深く絡み合った構造で広がっていくことになるだろうというのが既に見えている。
というのも、AIほとんど影響ないちょい前の時点ですら「うちはDDD、TDD、クリーンアーキテクチャ、k8s、アジャイル、スクラム等々を採用して云々」ってプロダクトが、リリースから半年、1年で開発がスタックしている、という事例は一般が想像する以上に存在している。
リリース時は、CTOやマネージャが腕組みしてWebページで華々しい成果発表するものだが、その裏で手動運用のオンパレード、一箇所変更したらどこに影響が及ぶかわからない地雷原、不具合障害が発生するたびに増える監視サービス、手動運用マニュアル。
その前で、「圧倒的ではないか、我がプロダクトは」って悦に入る経営陣、の図。
それ見て「SaaS界のネズミー王国や〜」って妄想を迸らせる利用者側経営陣と、ブルシットな手数だけ増えて、業績給与はぴくりくらいしか動かないで悶絶する利用者側従業員。
この状態で、「いや〜、新技術の導入、失敗しましたわ〜。経費が5倍くらいに膨れ上がってます。ごめんちゃい」なんてリリース出せないでしょ。
それ見て教科書ガイドエンジニア、カタログショッピングエンジニアが「世界を変える！ 俺(の業務経歴書)が変わる！！」って初見手探りで導入して、連れション地獄。
これが現状よ。
ここにAI が入ってくると、ますます「中身も、他の処理との関係性もよくわからんけどプロダクトに組み込まれた謎プログラムの塊」が、「これ以上機能を載せるとバランスを崩して全体が倒れる」寸前のサイズまで育つわけよ。
ここまで行っちゃったら、どこをどうしたらどうなるか、「AI 使ってふふふふ〜ん」ってレベルのエンジニアでは太刀打ちできなくなってるだろう。
すっと
「動くな！」
となって、対策のための会議とドキュメントづくりが延々と半年とかいうオーダーで繰り広げられることになる。
その間やれること、というかやらなきゃならないことは、障害対応手動運用。
こういう状態に陥らせたリーダーやリードテック、CTOは「新しいことに挑戦したいので」と敵前逃亡、成果発表のWebページを担いで次の犠牲者の元へ。
ちゃんと設計したら、生成AIを駆使する必要、あまりないはずなんだよなー。
で、テストも書いてくれる、っていうけど、AI に全投げ似非エンジニアにその妥当性とか、判断できんのかな？
カバレッジを100％に近づけるためだけのテストを手動で大量に書くのを代替してくれるかもしれないけど、あのテストが品質保証、障害対策になってる現場が一つでもあるか？
今流行りらしい、業務ドメイン分割マイクロサービスだと、AI で辻褄合わせてテストとか、無理やぞ。
という地獄が、2、3年後訪れるだろう。
楽しみやなぁ〜w
という話をすると、AI使いこなせないオールドタイプの負け犬の遠吠え、みたいにいうてくるのがいるんだけど、むしろAI を効果的に活用するための構造、構成とか模索してんのよ。
先人達の記録を多いに参考にさせていただきましたが、教材などが中心で勉強方法の情報が少なく感じたので、私の具体的な勉強方法を記録しておきます。
その後、
