はじめに 今後のAI時代に必要な「抽象を扱う力」とは 今後のAI時代において、抽象という領域を扱う能力は非常に大事なっていくと言われています。生成AIはコードやテストケースなど、それらを作る具体の作業を代替しつつあるためです。 しかし、私の感覚を正直に言うと、「抽象を扱う力が重要」というのはその通りですが、ちょっと言い足りない気がしています。 というのも、実はAIは抽象化がかなり得意です。大量の具体例から共通項を抜き出して概念化する作業はむしろ人間より速いのです。そのため、「抽象化できる人が強い」という単純な話だと、すぐにAIに追いつかれてしまうかもしれません。 私が大事だと思うのは、「何を抽象化の対象として選ぶか」という手前の判断力です。世の中には抽象化できるものが無限にあって、AIはお題を与えられれば見事に処理してくれます。でも「今、この状況で、何について考えるべきか」を決めるのは人間の仕事として残り続けるはずです。それは問題設定力、もしくは問題発見力と言えるものなのかもしれません。 もう一つは、抽象化された後の世界に居続けられる力です。それはつまり、「具体と抽象を往復する力」です。綺麗に抽象化をすることができると、物事がスッキリ整理されて、見通しが良くなります。一方で、現実は具体の積み重ねで動いています。抽象というモデルからこぼれ落ちたことや抽象にぼやかされた中にこそ本質があったりします。これは、一度具体に降りてそれを発見し、また抽象に戻り、先ほどとは異なる抽象モデルを発見しないと気づくことができません。 抽象化されたモデルを疑う力が今後問われる イギリスの統計学者George Boxは「すべてのモデルは間違っている、しかし有用である」と述べました。この名言において最も重要なことは、モデルとは現実を完全には写し取れず、あくまで近似であるということです。 テストやQAにおける「手順書」「チェックリスト」「方法論」は、いずれも「現実（仕様・ユーザー行動・制約・リスク）」を扱いやすくするためのモデルです。天気予報が地球の気象を完全には再現できず、様々な要因が絡み合った結果外れてしまうように、ガンダムのプラモデルがガンダムではないように、現実を扱いやすく抽象化したものでしかありません。近似とは、そのような性質を持っています。 モデルである以上、必ず取りこぼしや歪みが生じます。だから、手順や方法論に「盲従」しても完全にはなりません。そのため、抽象化する力よりも、抽象化されたモデルを疑う力が、AI時代には希少になっていくと考えています。 その上で、今後の人材には抽象を扱う力が重要であると考えます。それは何を抽象化するかを判断する力です。それは抽象と具体を往復する力です。これらを抽象化すると「思考力」と言うことができます。考える力です。この連載を通して、考える力とは何かについて少しでも皆さまの解像度を上げるお力になれれば幸いと考えています。 分類学と抽象化 非常に唐突ですが、分類学という学問があります。分類学とは、地球上に存在する多種多様な生物を、共通の特徴に基づいて整理し、グループ分け（分類）して、それぞれに名前を付ける（命名）学問のことです。この、名前をつけるという行為はまさに抽象化です。 分類学は、以下のような重要な目的を果たします。 情報の整理: 数百万種とも言われる生物を整理することで、生物の多様性を理解しやすくします。 進化の解明: 以前は「見た目（形態）」を中心に分類していましたが、現在はDNA解析などの技術が進み、生物同士が進化の過程でどのように分かれてきたか（系統関係）の解明に役立っています。 さて、分類学の面白い一面を紹介したいと思います。動物のグループ分けには、鯨偶蹄目という哺乳網の1目があります。鯨偶蹄目は、主にラクダやイノシシ、カバなどが含まれています。 鯨偶蹄目は、以下のようなグルーピングになっています。 鯨偶蹄目（Cetartiodactyla） ┃ ┣━ 核脚亜目（Tylopoda） ┃　　┗ ラクダ科（ラクダ、リャマ） ┃ ┗━ Artiofabula類 　　┣━ 猪豚亜目（Suina） 　　┃　　┗ イノシシ科（ブタ、イノシシ）、ペッカリー科 　　┃ 　　┗━ Cetruminantia類 　　　　┣━ 反芻亜目（Ruminantia） 　　　　┃　┣━ マメジカ下目（Tragulina） 　　　　┃　┗━ 真反芻下目（Pecora） 　　　　┃　　　┗ ジャコウジカ科、シカ科、ウシ科、キリン科、プロングホーン科 　　　　┃ 　　　　┗━ 鯨河馬形類（Cetancodonta） 　　　　　　┣━ カバ下目（Ancodonta） 　　　　　　┃　┗ カバ科（カバ、コビトカバ） 　　　　　　┗━ 鯨類（Cetacea） 　　　　　　　　┣ ヒゲクジラ小目（シロナガスクジラ） 　　　　　　　　┗ ハクジラ小目（マッコウクジラ、イルカ） このツリーの最後に注目してみてください。鯨偶蹄目はラクダやイノシシの仲間と言いましたが、鯨も含まれています。それはなぜでしょうか。 答えは、偶数の蹄があるためです。そのため鯨偶蹄目という名前という名前がついているのですね。実はこのツリーが示す通り、クジラはカバの親戚であることがここ最近の研究でわかりました。ここで、「クジラには蹄なんてないじゃないか！」と思ったことでしょう。実は、水中生活へ適応する進化の過程で後ろ脚や蹄は完全に消失し、現在では骨盤や大腿骨の小さな痕跡が体内に残っていることが研究でわかりました。 さらに、外見上の特徴だけでなく、内臓のつくり、特に「胃」の構造や消化の仕組みにも、進化の足跡が色濃く残されています。 注目すべきは、胃が一つ（単胃）なのか、それとも複数（複胃）なのか。そして、一度飲み込んだ食べ物を口に戻して噛み直す「反芻（はんすう）」を行うかどうかという点です。 例えば、ウシが4つの胃を持っていることは、焼肉がお好きな方ならよくご存じでしょう。焼き肉上の呼び名に、「ミノ、ハチノス、センマイ、ギアラ」があります。これらはいずれも焼肉店でお馴染みの部位ですが、実はすべてウシの胃にあたります。ウシはこの4つの胃を駆使して植物を分解し、反芻を繰り返すことで効率よく栄養を吸収しているのです（焼き肉上の呼び名ってなんだ）。 対照的なのが、同じ草食動物でも奇蹄目に属するウマです。ウマの胃は人間と同じく一つしかありません。その代わり、彼らは巨大に発達した「盲腸」の中に微生物を飼い、そこで時間をかけて食べ物を消化しています。 改めて、そこで再びクジラに注目してみましょう。実はクジラも、複数の胃を持つ動物です。種によって異なり、3つのものから、ツチクジラのように13個もの胃を持つ例外も存在しますが、「胃を複数持つ」という点はウシなどの仲間と共通しています。しかし一方で、クジラは反芻を行いません。この点はウシとは明確に異なります。 ここで重要になってくるのがカバの存在です。カバの胃は3つあり、クジラと同様に「複胃でありながら反芻はしない」という特徴を持っています。この消化器官の共通性は、クジラがウシよりもカバに近い系統であることを示す、有力な証拠の一つとなりました。 このように、現代の分類学はDNA解析だけで決まるわけではありません。内臓の構造や消化の仕組みといった解剖学的な特徴を緻密に比較することで、生物が進化の過程でどのように枝分かれしてきたのか、その壮大な物語をグルーピングしているのです。 抽象化とは、共通する本質的な要素を抜きだすこと さて、抽象化をイメージしやすいように非常に長々と書いてしまいましたが、抽象化とは、具体的な事柄から共通する本質的な要素を抜き出して、一般的な概念やモデルを作ることを指します。抽象化によって概念やモデルが作られると命名することができます。分類学はまさに多様な生き物のモデルを作っています。 抽象化は、具体という複雑なものを単純化し、本質を捉えることができます。これを垂直な思考と呼んだり、ボトムアップと呼んだりします。 抽象化の目的は、複雑さを減らして本質を理解しやすくすることです。 例えば、「柴犬」「プードル」「チワワ」などの個々の個体から、「4本足で歩く」「哺乳類である」「人に懐く」といった共通の特徴を抜き出して「犬」と名付けることができるかもしれません。様々な企業の成功事例から、「顧客中心主義」「迅速な意思決定」といった共通の成功要因を抜き出すことも抽象化です。 グルーピングをして名前をつけるということは、抽象化とは複数の具体に対して1つの抽象が対応するような「N:1」の関係が成り立つことがわかります。 再び鯨偶蹄目のツリーを見てみましょう。鯨偶蹄目に対して、たくさんの対応関係が紐づいていることがよくわかります。 鯨偶蹄目（Cetartiodactyla） ┃ ┣━ 核脚亜目（Tylopoda） ┃　　┗ ラクダ科（ラクダ、リャマ） ┃ ┗━ Artiofabula類 　　┣━ 猪豚亜目（Suina） 　　┃　　┗ イノシシ科（ブタ、イノシシ）、ペッカリー科 　　┃ 　　┗━ Cetruminantia類 　　　　┣━ 反芻亜目（Ruminantia） 　　　　┃　┣━ マメジカ下目（Tragulina） 　　　　┃　┗━ 真反芻下目（Pecora） 　　　　┃　　　┗ ジャコウジカ科、シカ科、ウシ科、キリン科、プロングホーン科 　　　　┃ 　　　　┗━ 鯨河馬形類（Cetancodonta） 　　　　　　┣━ カバ下目（Ancodonta） 　　　　　　┃　┗ カバ科（カバ、コビトカバ） 　　　　　　┗━ 鯨類（Cetacea） 　　　　　　　　┣ ヒゲクジラ小目（シロナガスクジラ） 　　　　　　　　┗ ハクジラ小目（マッコウクジラ、イルカ） これを言葉に置き換えてみると、 曖昧な言葉は複数の解釈を生む ことがわかります。犬といっても、チワワもいるし、ダックスフンドもいるし、ゴールデンレトリーバーもいる。これが「曖昧なことを言われてもわからないよ」となってしまうことの正体です。 一方で、抽象化は応用が効きます。 「複数の異なる事象の間にある『共通のルール（本質）』を取り出せるから」 です。「具体」の世界に留まっていると、新しい問題が起きるたびにゼロから考えなければなりません。しかし「抽象」という武器を持っていれば、過去の経験を「あ、これはあのパターンと同じだ」と当てはめて解決できるようになります。これが「応用が効く」という仕組みの正体です。 アナロジーという応用 アナロジーとは、「類推」や「類比」を意味し、ある事柄（ベース）をもとに、類似点を持つ他の事柄（ターゲット）について推し量る考え方です。具体的には、異なる事柄の間に共通点を見つけ出し、その共通性を利用して未知の事柄を理解したり、解決策を導き出したりします。 私が長々と例に挙げた「分類学」も、抽象を説明するためのアナロジーです。これは、ある領域から別の領域に思考を広げる、水平な思考と呼ばれる思考法です。未知のものを既知に例えることで理解を助けることができます。そのほかにも、既知の領域の知識を応用し、新しいアイディアや解決策を発想することができます。 例えば、 「原子の構造」を「惑星が太陽の周りを回る太陽系」に例えて説明することができます。 「コンピューターウイルス」の振る舞いを、「体内に侵入して増殖する生物のウイルス」に例えることができます。 次回へ続く 次回、「『思考の武器』をテスト・QAの現場に活かす」へ続きます！ 私たちが手に入れた抽象化とアナロジーの力が、日々の検証業務をどう変えるのかについてお話しします。 The post 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 first appeared on Sqripts .

こんにちは。クラウドエース株式会社 第一開発部の阿部です。Zenn 初投稿です。 同じ第一開発部の喜村さんが公開した Cloud Armor の誤検知をクエリで炙り出してチューニングする を読んで、Log Explorer で AND NOT を積み重ねながら誤検知を洗い出す手法を実践しました。この手法は 見落としが起きにくく、優れた方法 だと感じています。 ただ、規模が大きいログを手作業で回し続けるのは想像以上に大変で、「前処理だけでも自分用に楽にできないか」と考えました。そこで Cursor を相棒に、AI 駆動開発で前処理用の Web UI を作ってみた というのが本記事です。 ツ

目次 1. はじめに 2. 検証環境 3. Downsampling の設定方法 4. Downsampling の実行と容量削減効果 5. ES|QL（TSコマンド）によるデータ確認と注意点 6. まとめ 7. 参考URL 1. はじめに Elastic Stackの比較的新しい機能として、 TSDS (Time Series Data Stream)  に対する  Downsampling（ダウンサンプリング）  がサポートされています。 これは、例えば「1秒ごとに収集された高頻度なメトリクス」を「1分ごと、あるいは1日ごとの統計値」へと自動的に集計・集約することで、データ量を劇的に削減し、長期保存データのクエリを高速化するための機能です。 今回は、この Downsampling 機能が実際にどのように動作し、どれほどの効果があるのかを検証してみました。 2. 検証環境 今回の検証は、以下の環境で行いました。 Elastic Stack:  v9.4.2 (Self-Managed, Trial License) 収集データ:  Elastic を動作させている Windows ホストのパフォーマンスメトリクス（OpenTelemetry Collector経由） 3. Downsampling の設定方法 Downsampling の実行方法はいくつかありますが、今回は最も実用的な  Index Lifecycle Management (ILM)  のポリシー内に組み込む方法を採用しました。 ILMポリシー名:   metric-otel-ilm-policy フェーズ遷移: Hotフェーズ:  データのインジェストと直近データの保持 Coldフェーズ:  移行タイミングで Downsampling を実行 Downsampling interval:   1 days  （1日粒度に集約） ※参考画面 💡  ※注意:  今回の  1 days  という設定値は、検証結果（変化）をわかりやすく確認するための極端な設定です。本番環境での推奨値ではありません。 4. Downsampling の実行と容量削減効果 設定後、データがある程度蓄積され、インデックスが Rollover して Cold フェーズへ移行するのを待ちました。 Cold フェーズ移行前後のデータ量の変化は以下の通りです。 ステータス ドキュメント数 インデックスサイズ Rollover 直前 (Hotフェーズ) 約 650,000 件 約 20 MB Cold フェーズ移行後 (Downsampling 適用後) 5,865 件 1.14 MB インデックスサイズが約20分の1、ドキュメント数にいたっては 約110分の1 にまで圧縮されており、期待通りの強力なデータ削減効果が確認できました。 （※注　メトリクスは24時間取得していたわけではありません。24時間取得し続けていたら、もっと大きな圧縮率になっていたと思われます。） ※Cold フェーズ移行後の参考画面 （※Rollover 直前のデータ量に関するスクリーンショットは取り損ねてしまいました。） 5. ES|QL（TSコマンド）によるデータ確認と注意点 Kibana の Discover から、ES|QL の  TS  コマンドを使用して、格納されたデータを集計してみます。 TS metrics-hostmetricsreceiver.otel-default* | WHERE state == "free" or state == "used" | STATS mem = AVG(metrics.system.memory.usage) BY TBUCKET(1h), state | KEEP `TBUCKET(1h)`, mem, state | SORT `TBUCKET(1h)` desc, state ※参考画面 クエリ結果の考察 出力された結果（一部抜粋）を確認すると、Downsampling の仕様が顕著に現れた挙動を示していました。 TBUCKET(1h) mem state データの特徴 Jun 12, 2026 @ 11:00:00.000 11,889,684,480 free (*1) Jun 12, 2026 @ 11:00:00.000 21,892,382,720 used (*1) Jun 12, 2026 @ 10:00:00.000 11,387,027,456 free (*1) Jun 12, 2026 @ 10:00:00.000 22,395,039,744 used (*1) … … … … Jun 9, 2026 @ 09:00:00.000 12,531,630,920.205 free (*2) Jun 9, 2026 @ 09:00:00.000 21,250,436,279.795 used (*2) Jun 8, 2026 @ 09:00:00.000 14,159,069,970.101 free (*2) Jun 8, 2026 @ 09:00:00.000 19,622,997,229.899 used (*2) Jun 7, 2026 @ 09:00:00.000 7,128,812,202.667 free (*2) Jun 7, 2026 @ 09:00:00.000 26,653,254,997.333 used (*2) … … … … (*1) 直近データ（未圧縮）、1時間単位で取得可能 (*2) Downsampling 適用済み（1日1バケットのみ出力） クエリでは TBUCKET(1h)（1時間ごと）の集計を要求しているにもかかわらず、Cold Tier に格納されている過去データ（Jun 9 以前）は「1日（24時間）に1データ」しか返ってきていません。 これは、Downsampling によってデータがすでに 1 days の粒度に丸められ、それより細かい時間軸のデータが消失しているためです（内部的に事前集計された代表値のみが残るため）。クエリ側でどれだけ細かいバケットを指定しても、保持されている最小粒度（今回は1日）でしか結果を得られないという特性がよくわかります。 検証用のデータのためクエリの速度向上までは測定できていませんが、集計対象のデータ量が劇的に少なくなっているため、理論上は従来よりも大幅な速度向上が見込めます。 6. まとめ 今回、Elastic TSDS の Downsampling 機能を検証し、以下のことが分かりました。 圧倒的なストレージ削減効果 ドキュメント数やデータサイズを劇的に削減できるため、長期的なトレンド分析用のインデックスにおいて非常に有効です。 データ粒度とのトレードオフ 今回の検証結果が示す通り、Downsampling を適用した期間のデータは、指定したインターバルより詳細な分析（例：瞬間的なスパイクの検知など）ができなくなります。 実運用においては、 直近のトラブルシューティング用に、Hot フェーズでは生データを数週間保持する。 それ以降の長期的なキャパシティプランニング用に、Warm/Cold フェーズで1時間〜1日粒度へDownsampling する。 といった、要件に合わせたメリハリのあるILMポリシーの設計が重要になりそうです。 7. 参考URL Configuring a time series data stream for downsampling Downsample Elastic’s metrics analytics gets 5x faster Configure downsampling directly in Elastic Streams, no more JSON editing needed The post Elastic TSDS の Downsampling 機能を試してみた first appeared on Elastic Portal .