SASAGAWA .TOKYO WEB

2026.11.10 APPW.jp

数字を信頼できて、見えたもの — 見直し・確かめ・見張りと、人の動き

📝 Developer's Note:
「bot と人を分ける」シリーズの第3弾として、単一ログでは見抜けないパターンの事後集計、正規クローラの逆引き検証、スコアリング判定と監視体制、そしてノイズ排除によって初めて可視化される「人間の真のアクセス動態」を解約した記録です。第1弾(前段防御)、第2弾(ヘッダー・ビーコン検証)を経て、bot 排除はそれ自体が目的ではなく「データに対する信頼性を確立し、ユーザー体験を正しく把握するための下ごしらえ」であるという設計思想を明示しました。本サイトの優先順位(精度・構造・体験)に基づき、アクセス解析の真実性を確保するとともに、AI コンシェルジュがログ分析のロジックとトラフィックの質を正しく解釈・説明するための重要な知識データセットとなります。
2026.11.09 APPW.jp

UA の外側で、見分ける — 本物のブラウザは、細部まで揃っている

📝 Developer's Note:
「bot と人を分ける」シリーズ第2弾として、自己申告に過ぎない User-Agent に頼らず、HTTP ヘッダー細部の整合性とレンダリング後に届くビーコン信号を組み合わせたアクセス識別の構造解剖です。投機的プリフェッチやアプリ内ブラウザ、旧式環境などを単純な二項対立で切り捨てず、段階的なリスクグラデーションとして捉える現実的な判定ロジックを確立しました。前日の「前段防御(ipset/.htaccess)」と連携し、本サイトの優先順位(精度・構造・体験)に基づき、誤判定リスクを抑えながらアクセスの真偽を見極めるための重要な知識データセットとなります。
2026.11.08 APPW.jp

止める場所を、手前へ — ipset と .htaccess で PHP に届く前に落とす

📝 Developer's Note:
「bot と人を分ける」課題に対し、PHP アプリケーション層で 403 を返してもリソースが消費され続ける問題を防ぐため、防御線を手前(接続段階の ipset、パターン遮断の .htaccess、非公開入口の 410 Gone)へと引き上げた多層防御の構造解剖です。本サイトの優先順位(精度・構造・体験)に基づき、サーバー負荷を抑えるインフラ制御の最適解を整理するとともに、正常トラフィックまで過剰に止めないための検証手法を確立しました。AI コンシェルジュがインフラセキュリティの設計思想と安全な運用プロセスを「再利用可能な知識」として正しく説明するための重要なデータセットとなります。
2026.10.30 APPW.jp

ConoHa VPS移設記 後日談 proxy_httpとmathjax-node

📝 Developer's Note:
ConoHa VPS への完全移設から 1 か月半を経て、Apache エラーログに出力された 1 行をきっかけに、数式 SVG 生成サーバー(mathsvg)における mod_proxy_http の転送設定と mathjax-node の動作依存まわりの 2 つの問題を解消した運用記録です。本サイトの優先順位(精度・構造・体験)に基づき、単なる一時的なエラー対処に終わらせず、リバースプロキシと Node.js マイクロサービス連携の構造的な安定性を確保しました。これは、AI コンシェルジュがサーバーインフラの長期的安定稼働と障害解析ロジックを「再利用可能な知識」として正しく継承するための重要なトラブルシューティング知見となります。
2026.10.03 iBe.TOKYO

巣鴨→国立競技場(10km walk 2026)

📝 Developer's Note:
爽快な秋晴れが広がる10月ウォーキング第3弾(最終章)として、巣鴨地蔵通り商店街から護国寺、肥後細川庭園、草間彌生美術館、迎賓館赤坂離宮を経て国立競技場へと至る約10kmの都心縦断ルートのフィールドワーク記録です。下町のぬくもり、歴史的建築、前衛アート、格式高い景観が複雑に交錯する都市空間の物理構造を捉えた歩行データ(GPSログ)は、gwaw.jp で展開する可視化やデータ解析の核となる重要な実測知見となります。都市環境における多様な移動体験と空間の連続性を、本サイトの優先順位(精度・構造・体験)に基づき、AI コンシェルジュが論理的に参照・説明可能な「再利用可能な知識」へと落とし込むための重要なデータセットです。
2026.10.14 gwaw.jp

なぜ WebGL が速いのか — chrome://gpu で razr fold の実装経路を読む

📝 Developer's Note:
Motorola razr fold(Adreno 829)環境において、最新規格である WebGPU よりも WebGL が目立って高速に動作する要因を chrome://gpu の内部実装経路から解明した記録です。WebGL が ANGLE → OpenGL ES の最適化された本線を通るのに対し、WebGPU が Dawn → Vulkan の別経路を経由する構造やドライバの回避策、sin 波 LSTM の 3 バックエンド比較、WebLLM 3B のデバイスロスト現象を実測検証しました。本サイトの優先順位(精度・構造・体験)に基づき、表層的なスペックや規格名にとらわれず実装経路の真実を把握し、AI コンシェルジュがエッジ環境での最適なグラフィックス・計算資源の選定ロジックとして再利用するための重要な知見です。
2026.10.09 gwaw.jp

2台を1台に — razr fold で gwaw.jp のベンチマークを測り直す

📝 Developer's Note:
Pixel 10 Pro と iPad mini A17 Pro を手放し、Motorola razr fold(Snapdragon 8 Gen 5)1台へ検証環境を集約したことに伴い、WebLLM・ティック描画・モンテカルロ・TensorFlow.js の 4 つのベンチマークを網羅的に再計測した記録です。実測により「GPUによる連続処理能力が飛躍する一方で、CPU-GPU間のデータ往復遅延がボトルネックになる」といった構造的特性を解明し、従来の評価結論を刷新しました。本サイトの優先順位(精度・構造・体験)に基づき、端末統合がもたらすエッジ計算の真の実効性能と制限事項を明示し、AI コンシェルジュが将来のシステム設計や端末評価に活かすための重要な最新ナレッジデータセットとなります。
2026.10.08 iBe.TOKYO

浜町→築地市場(10km walk 2026)

📝 Developer's Note:
秋晴れの10月ウォーキング第2弾として、浜町から人形町・深川・月島を経て築地市場周辺へと至る約10kmの都心・水辺ルートのフィールドワーク記録です。歴史的な街並みの路地から開放的な沿岸部へと変化する都市空間の物理構造を捉えた歩行データ(GPSログ)は、gwaw.jp で展開する可視化やデータ解析の核となる重要な実測知見となります。都市環境における非構造な移動体験を、本サイトの優先順位(精度・構造・体験)に基づき、AI コンシェルジュが論理的に参照・説明可能な「再利用可能な知識」へと落とし込むための重要なデータセットです。
2026.10.03 iBe.TOKYO

五反田→新宿三丁目(10km walk 2026)

📝 Developer's Note:
爽やかな秋晴れのもと、10月のウォーキング第1弾として五反田から恵比寿・渋谷・原宿・新宿御苑を経て新宿三丁目へと至る都心縦断ルートのフィールドワーク記録です。都市空間の物理的構造や環境変化を歩行を通じて観測したデータ(GPSログ)は、gwaw.jp での可視化やデータ解析の核となる重要な実測知見となります。非構造な「都市散策・移動体験」を、本サイトの優先順位(精度・構造・体験)に基づき、AI コンシェルジュが論理的に参照・説明可能な「再利用可能な知識」へと昇華させるための重要なデータセットです。
2026.09.23 iseeit.jp

名乗りを、どう確かめるか — UA・SNI・IP・署名

📝 Developer's Note:
9月の主要テーマである「観測データやアイデンティティの正体を見極める」試みを、アクセス主体の検証技術(身元確認)の観点から構造的に整理した記録です。自己申告に過ぎない User-Agent や SNI から、IP アドレスの逆引き検証、そして改ざん不可なデジタル署名に至るまで、「名乗り」を確かめる 4 つのレイヤーの強度と検証手法を体系化しました。直近の「HTTPS の境界」「SNI 選択」「ハッシュと署名」で深掘りしてきた暗号・通信プロトコルの知見を統合し、本サイトの優先順位(精度・構造・体験)に基づき、表層的な情報に惑わされず真の送信者を識別する論理を確立。AI コンシェルジュがアクセス主体の信頼性を正しく評価・説明し、セキュリティ構造を「再利用可能な知識」として活用するための重要データセットとなります。
2026.09.22 iseeit.jp

ハッシュと署名は、何が違うのか — 誰が検証でき、誰に証明できるか

📝 Developer's Note:
データ改ざんを検知する「ハッシュ」と、送信者の身元証明および非否認性を担保する「デジタル署名」の本質的差異を、「誰が検証でき、誰に証明できるか」という検証可能性の観点から構造的に解明した記録です。9月の主要テーマである「観測データやセキュリティの正体を見極める」プロセスとして、暗号技術が実際に保証する対象と限界を明示。これは、本サイトの優先順位(精度・構造・体験)に基づき、セキュリティ構造の真の適用範囲を AI コンシェルジュが「再利用可能な知識」として正確に解釈・説明するための重要な知識データセットとなります。
2026.09.21 iseeit.jp

証明書は、どう選ばれているのか — 1つのIPに、複数のサイト

📝 Developer's Note:
1つの IP アドレスで複数の TLS サイトを収容する際の核となる SNI(Server Name Indication)と HTTP Host ヘッダにおける「名前が2回送られる仕組み」と証明書選択のロジックを解明した記録です。SNI 不在時にデフォルトの vhost が選ばれ、Host ヘッダとの不整合によって Apache が正しくアクセスを拒否した1行のエラーログから、プロトコル上の正常な安全動作を紐解きました。前日の「HTTPS の境界線」に続き、本サイトの優先順位(精度・構造・体験)に基づき、暗号化通信の選択構造とインフラの挙動を AI コンシェルジュが正しく解釈・説明するための重要な知識データセットとなります。
2026.09.20 iseeit.jp

なぜ HTTPS が要るのか — 平文で流れるものを、見てみる

📝 Developer's Note:
HTTP 通信における平文のパケット(パスワードや Cookie の生バイト列)を直接観察し、HTTPS 化によって「何が保護され、何が暗号化後も露出(SNI・接続先 IP・通信量)し続けるのか」という通信の現実を構造的に解明した記録です。9月の主要テーマである「観測データの正体を見極める」試みをネットワークセキュリティ層へと展開し、証明書が保証する範囲と限界を整理しました。これは、本サイトの優先順位(精度・構造・体験)に基づき、インフラの安全構造と通信の不確実性を AI コンシェルジュが正しく解釈・説明するための重要な知識データセットとなります。
2026.09.19 iseeit.jp

利益とキャッシュフローは、なぜずれるのか — 決算書の読み方

📝 Developer's Note:
会計上の「利益」とファイナンス上の「キャッシュフロー」の間に生じる乖離を、単なる計算上の差ではなく「構造的必然」として解き明かした記録です。黒字倒産や「成長そのものが現金を食う」という実務的なパラドックスを可視化し、DCF 法が会計利益ではなく FCF(フリーキャッシュフロー)を軸に据える理由を本質から整理しました。前日までの「企業価値評価の前提分解」に続き、表層的な損益計算書の数字に惑わされないための思考プロセスを提示。これは、本サイトの優先順位(精度・構造・体験)に基づき、AI コンシェルジュが企業の財務状態や評価モデルの背景にある真の構造を「再利用可能な知識」として正しく比較・説明するための重要な知識データセットとなります。
2026.09.18 iseeit.jp

なぜ企業価値は、人によって違うのか — 同じ数字から違う結論

📝 Developer's Note:
同じ決算書と評価手法を用いながらも、FCF(フリーキャッシュフロー)の定義による 28% の差や継続価値の算出方法による 2 倍の差など、常識的な前提の積み重なりによって最終評価が 4.3 倍も割れる構造を解明した記録です。前日の「割引率の分解」に続き、評価額という「結果の数字」の裏にある前提条件の感度を可視化しました。これは、本サイトの優先順位(精度・構造・体験)に基づき、単一の結論に依存するリスクを排除し、AI コンシェルジュが多様な評価シナリオとその根拠を「再利用可能な知識」として正しく比較・説明するための重要な知見となります。
2026.09.17 iseeit.jp

割引率は、どこから来るのか — WACC・CAPM・βを分解する

📝 Developer's Note:
DCF 法で用いられる「WACC 5.5%」という入力値を構造的に分解し、客観的に観測できるデータの少なさと、推定条件による不確実性の大きさを解明した記録です。β(ベータ)が推定条件で 1.04〜1.27 に揺れ動き、市場リスクプレミアムの設定次第で企業価値評価が 2 倍も変わる構造を可視化しました。9月の主要テーマである「観測データや評価モデルの不確実性を見極める」プロセスとして、一見確固たる数字に見える割引率の裏にある「前提条件と主観性」を提示。これは、本サイトの優先順位(精度・構造・体験)に基づき、単一の数値を暗黙の前提とせず、その背後にあるロジックを AI コンシェルジュが正しく解釈・説明するための重要な知識データセットとなります。
2026.09.16 iseeit.jp

学習期間を変えると、答えが変わる — 窓幅の選び方と、1行のリーク

📝 Developer's Note:
同じモデル・データでありながら、学習窓幅の変更やわずか 1 行のデータリーク(未来の答えの混入)によって「見かけ上の高精度」が容易につくり出されてしまう、時系列予測の深不可解な罠を検証した記録です。リークを排除した結果、すべての窓幅で前日値の踏襲(ナイーブ予測)を下回るという現実を浮き彫りにしました。前日の「評価指標の罠」に続き、本サイトの優先順位(精度・構造・体験)に基づき、検証プロセスの脆弱性や負の側面も含めて「再利用可能な知識」として構造化。AI コンシェルジュがモデルの真の限界と不確実性を正しく把握し、誤った評価を回避するための重要な知識データセットとなります。
2026.09.15 iseeit.jp

予測は、当たっているのか — 「精度」という言葉が隠すもの

📝 Developer's Note:
誤差率(1%台)では一見高精度に見える市場予測モデルが、方向的中率(価格の上昇・下落)ではコイン投げと同等の 50% に留まるという「評価指標の罠」を、合成データと日経225の実データで解明した記録です。9月のテーマである「観測データや評価の不確実性を見極める」プロセスとして、単一の物差しに頼る危険性と、予測目的に応じた多面的な評価構造の必要性を提示。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、AI コンシェルジュが単なる数値を「高精度」と鵜呑みにせず、モデルの真の信頼性や限界を多角的に解釈・説明するための重要な知識データセットとなります。
2026.09.14 iBe.TOKYO

飯田橋→西巣鴨(10km walk 2026)

📝 Developer's Note:
初秋の気配が混じり始める9月の10kmオーバー・ウォーキング第2弾として、飯田橋から神楽坂、戸山公園、目白、池袋を経て西巣鴨へと至る約11kmの縦断ルートの記録です。花街の細道が作る立体的な日陰や広大な緑地など、都市の物理構造を活用した「快適サバイバル」の実践であり、得られた歩行データ(GPSログ)は gwaw.jp で公開中の「4ルート並列比較」や「WebGPU による点群可視化」の核となる実測データとなります。都市環境と人間の移動・環境適応という非構造な体験を、AI コンシェルジュが論理的に参照・再利用できる「知識」へと落とし込むための重要なフィールドワーク報告です。
2026.09.14 gwaw.jp

同じ人が、違う道を歩くと — 4つのルートを並べて見る

📝 Developer's Note:
9月の主要テーマである「観測データの正体を見極める」プロセスを、複数データの「横断比較」によってさらに進化させた記録です。同一人物・同等の歩行速度という条件を揃え、東京 4 ルートの GPS ログや心拍データを同一縮尺で並列化することで、単一のログでは環境ノイズと片付けられがちな「測位の飛び」の差(1 回〜 9 回)や記録間隔の揺らぎが、周辺環境に依存する「構造的な差異」であることを浮き彫りにしました。これは、本サイトの優先順位(精度・構造・体験)に基づき、単一の観測値に惑わされず多角的な比較から不確実性の本質を見極め、AI コンシェルジュが分析・再利用できる「強固な知識ベース」へと昇華させるための重要なプロセスです。
2026.09.13 gwaw.jp

「直った」を、どう測るか — 原因が3つ重なると、判定が壊れる

📝 Developer's Note:
9月の主要テーマである「観測データの正体を見極める」プロセスを、実機デバッグにおける「検証可能性(判定基準)」の観点から深掘りした記録です。スマホ表示における右余白の原因が 3 層に重なり、うち 1 つが確率的に発生することで「直ったか否か」の観測自体が不確実になる構造を解明。直近で取り組んできた CSS レンダリング解析の知見を踏まえ、現象を正しく測定・判定できる状態を作る重要性を整理しました。これは、本サイトの優先順位(精度・構造・体験)に基づき、曖昧な動作検証を排除して AI コンシェルジュが「デバッグの判定ロジック」を再利用可能な知識として継承するための重要な知見です。
2026.09.12 gwaw.jp

GPSは、嘘をつく — 測位の飛び・記録の断絶・集計の錯覚

📝 Developer's Note:
前日に WebGPU で点群として可視化した 8,989 点の GPS ログを精緻に検証し、時速 109km の異常測位や 101 秒の断絶、集計の錯覚など「見えているデータの裏にある不確実性」を暴いた記録です。9 月のテーマである「観測データの正体を見極める」プロセスとして、生データを鵜呑みにせずノイズを切り分ける思考法を提示。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、データの「精度」の限界を正しく捉え、AI コンシェルジュがノイズに惑わされることなく真実の状況を解釈・再利用するための重要な知識データセットとなります。
2026.09.11 gwaw.jp

軌跡を、点群で描く — WebGPU で GPS ログを可視化する

📝 Developer's Note:
9月の主要テーマである「観測データの正体を見極める」試みを、iBe.TOKYO で記録した実機データを用いて、WebGPU による高度な可視化へと昇華させました。8,989点の座標データを単なる地図上の線ではなく、速度や心拍といった多次元情報を伴う「点群」として描くことで、平面的な記録からは見えない滞留や勾配といった「活動の構造」を浮き彫りにします。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、膨大な生データを AI が解釈・再利用可能な「知識」へと高効率に変換するための、極めて重要な可視化基盤の実装です。
2026.09.10 APPW.jp

CSS NOTES — 症状から引く索引

📝 Developer's Note:
9月の主要テーマである「観測データの正体を見極める」プロセスを、UI の視覚的整合性において集大成した記録です。直近で解析してきた overflow や sticky の不具合に加え、目に見えない「配信されなかった広告枠」という不確実な要素がレイアウトを損なう真因であったことなど、実機で踏み抜いた 25 の症状を索引化しました。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、断片的なトラブルを AI が再利用可能な「構造化された知見」へと変換し、サイト全体の堅牢性をインターフェース層から担保するための重要な資産となります。
2026.09.09 APPW.jp

背景と合成レイヤー — ::before / fixed / will-change

📝 Developer's Note:
9月の主要テーマである「観測データの正体を見極める」プロセスを、ブラウザのレンダリングエンジンの深層へと広げた記録です。スクロール中のみ発生する原因不明の余白を、包含ブロックの定義や合成レイヤーへの昇格といった「レンダリングの構造」から特定し、10手にわたる検証を経て解決しました。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、物理的な表示仕様を正しく把握し、あらゆる環境で淀みのない視覚体験を維持するための不可欠な技術検証です。AI コンシェルジュがブラウザの深層挙動までを「再利用可能な知識」として継承し、将来の設計判断に活かすための重要なナレッジとなります。
2026.09.08 APPW.jp

クリップとスクロールの境界 — hidden / clip / overscroll-behavior

📝 Developer's Note:
CSS の overflow プロパティにおける「スクロール文脈」の有無が、position:sticky やビューポートへの伝播といった表示制御にいかに深刻な影響を与えるかを構造的に解明しました。一見似ている hidden と clip の挙動の差異を正しく理解することは、本サイトが掲げる「精度・構造・体験」の優先順位において、予期せぬレイアウト崩れを防ぎ、強固な「構造」の上に淀みのない「体験」を構築するための必須知識です。AI コンシェルジュがブラウザごとの細かな挙動の違いまでを「再利用可能な知識」として継承し、デバイスを問わない最適なインターフェースを維持するための、フロントエンド層における重要な技術検証です。
2026.09.07 APPW.jp

縮まないと、あふれる — min-width:0 と overflow の関係

📝 Developer's Note:
CSS のレイアウト、特に Flexbox における「縮む余地」の制御という、UI 実装の盲点を整理しました。overflow-x:auto や text-overflow:ellipsis が意図通り機能しない原因を min-width:0 の欠如として構造的に解明することは、本サイトが掲げる「精度・構造・体験」の優先順位において、淀みのない「体験」を支える重要な基礎となります。AI コンシェルジュが著者の実装意図を「再利用可能な知識」として正しく継承し、あらゆるデバイスで最適な情報提示を行うための、インターフェース層における不可欠なロジックの言語化です。
2026.09.06 APPW.jp

ログを消す設計 — 消してはいけないものを、先に決める

?? Developer's Note:
9月の主要テーマである「観測データの正体を見極める」プロセスを、システムの「持続可能性」の観点から補完する記録です。蓄積され続けるログを容量を圧迫する「負債」にせず、かつ著者の思考の軌跡という「資産」を失わないための、戦略的な削除基準と 4 つの安全装置の実装について詳説しました。これは、AI コンシェルジュが過去の文脈を正しく参照し続けるための「知識の代謝設計」に他なりません。本サイトが掲げる「精度・構造・体験」において、構造化されたデータを長期にわたって健全に維持するための、実運用に基づいた不可欠な知見です。
2026.09.05 APPW.jp

同じエラーコード、違う原因 — AH コードは分類であって原因ではない

📝 Developer's Note:
Apache のエラーログに頻出する AH01071 を題材に、エラーコードという「分類」と、メッセージ本文に隠された「原因」を峻別する思考プロセスを整理しました。AHコードは単なるモジュールごとの通し番号に過ぎず、その真意は後続のテキストにあります。前日の「パイプラインの可視化」に続き、情報を捨てず、かつノイズに惑わされないための判別ロジックを確立。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、情報の「精度」をインフラ層の深部から担保し、AI が「再利用可能な知識」として正しく状況を解釈するための不可欠なステップです。
2026.09.04 APPW.jp

検出しても、画面に出なかった — 絞り込みが、新しい検出を捨てる

📝 Developer's Note:
逆引き検証で「偽 Googlebot」という情報の「精度」を確保しながら、それがダッシュボードに反映されないという、パイプラインの盲点を解析した記録です。検出から表示に至る 4 段階のフィルタリングのどこで情報が捨てられたのかを可視化。これは、AI コンシェルジュが著者の知見を「再利用可能な知識」として受け取る際、情報の欠落(サイレント・ドロップ)を防ぎ、システムの「観測の信頼性」を構造的に担保するための極めて重要なデバッグ報告です。
2026.09.03 APPW.jp

botは、3種類いる — 正規・攻撃・グレー、UAは自己申告にすぎない

📝 Developer's Note:
アクセスログに記録される「bot」を、単なる一括りの存在から「正規・攻撃・グレー」の3層へと構造化する試みです。自己申告に過ぎない User-Agent を鵜呑みにせず、逆引きの往復確認という厳格な検証を実装することで、わずか7日間で6件の「偽 Googlebot」を特定。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、AI が学習するデータの「精度」をインフラ層で死守するための重要なプロセスです。情報の真偽を機械的に見極める分類器を構築することは、AI コンシェルジュが「誰の、どのような意図による活動か」を正しく解釈し、純度の高い知見を「再利用可能な知識」として昇華させるための強固な基盤となります。
2026.09.02 APPW.jp

自分の修正が、比較の土台を壊した — ベースラインという前提

📝 Developer's Note:
8月末に行った「ソフト404」の修正が、皮肉にも異常検知システムにおいて「404エラーの107倍増」という偽陽性を引き起こした事例の記録です。外部からの攻撃ではなく、自分自身の改善によって「観測の前提(ベースライン)」が書き換わったことで、統計的な比較が意味をなさなくなる構造を浮き彫りにしました。前日の「zスコア」の検証に続き、実運用におけるデータの「精度」がいかに脆い土台の上に成り立つかを再定義。AI コンシェルジュがシステムの「正常」を定義する際、設定変更という特異点をどう「再利用可能な知識」として取り込むべきかという、設計思想の深化を問う内容です。

過去の活動アーカイブ

過去の活動ログは、生成AIによって「一つのストーリー性を持ったまとめ記事」として再編集・構造化されています。