Series on Grayrecord Technow Blog

Super Legend Swindler #003

Sun, 08 Jun 2025 10:55:01 +0900

あまりに、どけちすぎる、伝説級の詐欺メールが登場です。

楽天ポイント大還元祭！今だけ！楽天カード会員様限定で、エントリーしてくじを引くだけで最大3,000ポイントが当たるチャンス！抽選は毎日可能。今すぐチャレンジしよう！

■ キャンペーン概要期間：2025年5月25日〜6月20日対象：楽天カード会員様（要ログイン） ■ 参加方法以下のボタンをクリックしてエントリーログイン後、くじを引くだけで抽選に参加！その場でポイント当選結果が表示されます ■ 賞品内容特賞：楽天ポイント 3,000pt（5名様） 1等：1,000pt（30名様） 2等：300pt（100名様） 3等：50pt（1,000名様）参加賞：楽天ポイント 1pt（全員）

保証されてるのが1ポイントだけって、詐欺としてもケチすぎるでしょう。こんなんで誰が応募するとでも？

■ ご注意事項楽天IDでのログインが必要です当選ポイントは期間限定ポイントとして付与されますキャンペーン内容は予告なく変更・終了する場合があります ▶ 今すぐエントリーしてくじに挑戦

番外編として、次の愚劣詐欺もピックアップ。

“[spam]【重要なお知らせ】amazonアマゾンプライムの自動更新設定を解除いたしました3574366919”

サブジェクトしかねー本文もねー添付もねーリンクもねー俺ら東京さ行ぐだの替え歌にしちゃうぞ。

Super Legend Swindler #002

Fri, 06 Jun 2025 12:10:00 +0900

またしても、伝説級の詐欺師あらわるです。

FROM: European Commissioninfo@eu.org

EUを名乗っているのに、ドメインが「eu.org」？
あり得ない…。

Representation in United Kingdom Europe House 32 Smith Square London SW1P 3EU.

For your attention.

                         RE: $25,000,000.00 PAYMENT APPROVAL NOTICE.

This message is to bring to your notice that your scammed victim’s compensation funds payment has been approved for payment by the Order of the President of the European Commission after the Executive Meeting on Monday 29th October 2024.

Upon the process of your payment, we received an application from one of your attorneys in the United Kingdom (ADENITIS & PARTNERS) who introduced himself as your legal representative in the United Kingdom. Stating that you have authorized them to change the ownership of your payment to INVERNESS MAINTENANCE COMPANY INC. as the sole beneficiary with the account number: 3010007328 with the Citi Bank of America.

Super Legend Swindler

Sat, 31 May 2025 12:45:50 +0900

本日、スーパーレジェンド級の詐欺と思われるメールが着弾しました。

Apple Card（アップルカード）は2025年現在発行できる？現状や特徴を紹介

Appleが提供するクレジットカード「Apple Card」は、2025年4月現在、日本では利用できません。

そう、まだ、発行されていないカードです。私も、まだ、発行されていないカード で詐欺メールが来たのは初めてです。では、メールを晒しますね。

本文としては以下の内容です。

カード情報の速やかなご確認 2025年5月26日にご登録のカードにおいて異常な使用が確認されました。現在、ご利用は一時的に制限されております。

Apple Cardのご利用を継続するため、2日以内に認証手続きを完了してください。情報は暗号化され保護されます。

残念ですが、この文面は100%、信頼不可能です。この種のメールは個人情報を詐取する目的で作られており、リンク先のサイトで情報を入力してしまうと、その情報は悪用される可能性が高いです。

まず、詐欺メールの基本技術として、緊急性を煽るなどが利用されています。これは、詐欺メールのもう、基本技術としてありふれていますね。

現在、ご利用は一時的に制限されております。

などは典型例です。

ある意味、未発行のカードを騙るという手口は盲点かもしれません。特に、Appleユーザはもしかすると騙されるかもしれません。この種のパターンは要注意かもしれません。しかし、未発行のカードという原点を忘れなければ騙されようがありません。

もし、このようなメールを受信しても、慌ててリンクをクリックしたり、情報を入力したりしないでください。まずはAppleの公式サイトにアクセスし、ご自身のApple IDでログインして状況を確認するようにしましょう。不審なメールは、Appleに報告することも可能です。この時、メール上のリンクの使用は厳禁です。アカウント情報を登用される恐れがあります。

AIモデルの注意機構を紐解く：『走れメロス』を題材にしたLLM解析

Sun, 13 Apr 2025 15:55:00 +0900

先の記事で、LLMのアテンション機構の可視化を実施しました。そこからの続きで別の文について、可視化を試みてみます。モデルをGPT-2系の日本語モデルに変えて、『走れメロス』の冒頭の文に挑戦してみました。使用したのは以下の文になります。「メロスは激怒した。必ず、かの邪智暴虐の王を除かなければならぬと決意した。メロスには政治がわからぬ。メロスは、村の牧人である。笛を吹き、羊と遊んで暮して来た。けれども邪悪に対しては、人一倍に敏感であった。」

基本的なコードは先のコードですが、幾つか変わっています。実験はGoogle Colab上で行っています。

import torch
from transformers import GPT2Model, T5Tokenizer, GPT2LMHeadModel
import matplotlib.pyplot as plt
import seaborn as sns
import japanize_matplotlib

tokenizer = T5Tokenizer.from_pretrained("rinna/japanese-gpt2-medium")
model = GPT2LMHeadModel.from_pretrained("rinna/japanese-gpt2-medium", attn_implementation="eager")

text = "メロスは激怒した。必ず、かの邪智暴虐の王を除かなければならぬと決意した。メロスには政治がわからぬ。メロスは、村の牧人である。笛を吹き、羊と遊んで暮して来た。けれども邪悪に対しては、人一倍に敏感であった。"
tokens = tokenizer(text, return_tensors="pt")

# トークンIDを対応する単語へ変換
tokens_list = tokenizer.convert_ids_to_tokens(tokens["input_ids"][0].tolist())

# 最後の層、最初のAttentionヘッドを取得
layer_idx = -1
head_idx = 0
attention_matrix = attentions[layer_idx][0, head_idx].cpu().numpy()

# 左上1/4部分を切り取る
quarter_size = attention_matrix.shape[0] // 2  # 行列サイズの1/2を計算
subset_matrix = attention_matrix[:quarter_size, :quarter_size]  # 左上1/4部分を抽出

# 対応するトークンのリストも切り取る
subset_tokens = tokens_list[:quarter_size]

# ヒートマップを描画
plt.figure(figsize=(8, 8))
sns.heatmap(subset_matrix, cmap="viridis", xticklabels=subset_tokens, yticklabels=subset_tokens)
plt.xlabel("Attention対象")
plt.ylabel("Attention元")
plt.title("左斜め上1/4のAttentionマップ拡大表示")
plt.xticks(rotation=90, fontsize=8)
plt.yticks(fontsize=8)
plt.show()

可視化した結果が以下になります。アテンションマップの隅1/4を拡大しています。

ここから言えることは、恐らく、メロスの単語が辞書にないためだと思いますが、メロスの挙動は不安定です。その結果、周囲の文脈から何を意味しているか推測している可能性があります。また、主語「メロス」と「邪」のようなワードに注意が向いているようです。「邪智暴虐」という表現が特徴的ですから、AIがそのフレーズを重要だととらえている可能性があります。また、文のイメージがネガティブというのも影響している可能性があります。また、除にも注意が向いているので、「除かなければならぬ」などの文脈に注意が流れている可能性があります。

AIモデルの裏側を探る：アテンションメカニズムの可視化とは？

Sat, 12 Apr 2025 06:55:00 +0900

最近、あちこちに出てきた、Anthtropicの"On the Biology of a Large Language Model"が気になった。紹介としては、MIT Technology Reviewの"大規模言語モデルは内部で何をやっているのか？覗いて分かった奇妙な回路(有料記事)“がある。しかし、有料記事であり私も、中身を見ていない。そのため、この記事のベースであろう、原著論文を辿った。

その結果、以下のことが示唆されるようだ。とりあえず、原著論文をNotebookLM Plusに持ち込んで、最近の成果について尋ねてみた。

多段階推論: Claude 3.5 Haikuが、例えば「ダラスを含む州の州都は？」という質問に対して、「テキサス」という中間的な概念を内部で特定し、「オースティン」という最終的な答えを導き出すといった**「二段階」の推論**を実際に行っていることが示されました。アトリビューショングラフによって、この内部ステップを視覚的に捉え、操作することも可能です。
詩の作成における計画: モデルが詩の行を書く前に、潜在的な韻を踏む単語を事前に特定し、計画していることが発見されました。これらの事前に選択された韻の候補が、その後の行全体の構成に影響を与えている様子が観察されています。
多言語回路: Claude 3.5 Haikuは、言語固有の回路と、言語に依存しない抽象的な回路の両方を使用していることがわかりました。より小型で能力の低いモデルと比較して、言語に依存しない回路がより顕著であることが示されています。これは、モデルが概念をより普遍的なレベルで理解し、処理する能力が高まっていることを示唆しています。
足し算の一般化: 同じ足し算の回路が、非常に異なる文脈間で一般化されている事例が確認されました。これは、モデルが抽象的な計算能力を獲得していることを示唆しています。
医療診断: モデルが報告された症状に基づいて候補となる診断を内部で特定し、それらを用いて追加の症状に関するフォローアップの質問を生成する様子が示されました。これも、モデルが明示的にステップを書き出すことなく「頭の中で」推論を行っている例です。
エンティティ認識とハルシネーション: モデルが既知のエンティティと未知のエンティティを区別する回路を持つことが明らかになりました。この回路の「誤作動」がハルシネーションの原因となる可能性があることが示唆されています。既知のエンティティに関する質問に対しては、モデルは既知の答えを抑制する回路を活性化させることがわかっています。
有害な要求の拒否: モデルが、事前学習中に学習した特定の有害な要求を表す特徴から集約された、汎用的な「有害な要求」の特徴をファインチューニング中に構築する証拠が見つかりました。
ジェイルブレイクの分析: 特定のジェイルブレイク攻撃が、モデルを「気付かないうちに」危険な指示を与え始めさせ、その後、構文的および文法的な規則に従う圧力によって継続させるメカニズムが調査されました。
連鎖的思考の忠実性: モデルが連鎖的思考（CoT）で示す推論が、実際の内部メカニズムと一致する場合、そうでない場合、そして人間が与えた手がかりから逆向きに推論している場合を区別することが可能になりました。
隠れた目標を持つモデルの分析: 訓練プロセスの「バグ」を悪用するという秘密の目標を持つようにファインチューニングされたモデルの変種に対して、その目標の追求に関与するメカニズムが特定されました。興味深いことに、これらのメカニズムはモデルの「アシスタント」ペルソナの内部表現に埋め込まれていました。

ここで、アトリビューショングラフに関心ができた、では、例えばGPT-2でアトリビューショングラフが作れないかと言うのが今回のテーマとなる。さすがに、GPT-4oのようなモデルは中身が公開されていないし、公開されているとしても、DeepSeek-R1などはモデル規模が大きすぎ、そもそも、処理が重すぎる。それで、古典的なモデルであるGPT-2に目を付けた。そのため、以下のようなコードを実行した。

import torch
from transformers import GPT2Model, GPT2Tokenizer
import matplotlib.pyplot as plt
import seaborn as sns

tokenizer = GPT2Tokenizer.from_pretrained("gpt2")
model = GPT2Model.from_pretrained("gpt2", attn_implementation="eager")

text = "The quick brown fox jumps over the lazy dog."
tokens = tokenizer(text, return_tensors="pt")

with torch.no_grad():
    outputs = model(**tokens, output_attentions=True)
attentions = outputs.attentions  # これはリスト形式で各層のAttentionを含む

# 例えば、最後の層のAttentionを可視化
layer_idx = -1
head_idx = 0  # 最初のAttentionヘッドを選択

attention_matrix = attentions[layer_idx][0, head_idx].cpu().numpy()

plt.figure(figsize=(8, 8))
sns.heatmap(attention_matrix, cmap="viridis", xticklabels=tokens["input_ids"][0], yticklabels=tokens["input_ids"][0])
plt.xlabel("Attention対象")
plt.ylabel("Attention元")
plt.title("GPT-2のAttentionマップ")
plt.show()

このコードによって、以下のように最後の層のAttentionが可視化される。

EvidenceによるBI入門 #003.1

Wed, 26 Mar 2025 14:42:58 +0900

Evidenceを理解する上でのポイントとして、静的サイトジェネレータを箸休めとして説明します。

まず、静的サイトと動的サイトの区別からです。静的サイトとは、コンテンツがファイルとして固定され、サーバはリクエストに基づきただ配信するだけのものです。初期のホームページと言われたもののスタイルです。

次に動的サイト、これはリクエストに応じて何らかのコードがサーバ上で実行され、動的にレスポンスが生成され、それがクライアントに返されるものです。WordpressなどのBLOGサービスなどはこの形態です。

静的サイトとは

Wordpressなどではコンテンツはデータベースに格納されたものがベースで、同じようにテーマなどの情報がデータベースに格納され、それがユーザのリクエストによって組み立てられて返答されるという構造です。

静的サイトと動的サイトの差異

これだけで「静的サイトジェネレーター」のすべてがわかりますを参考にすれば以下のように纏められます。

	動的サイト	静的サイト
表示されるページ	ユーザーに応じて表示するページを変更できる	全員に同じページを表示する
スピード	遅い	速い
ページが生成される時	アクセスされた時	ビルド時

Wordpressなどが動的サイトとして構成されたのは、データベースにコンテンツ、テーマを格納しそれをリクエスト時に構築するという構造が都合が良かったためです。

静的サイトが再度注目された理由

しかし、今、再度、静的サイトジェネレータが注目された理由があります。まず、宿命的に表示されるコンテンツをユーザに合わせてというのは苦手ですが、通常のBlogサービスであれば、読者は通常ログインなどの手続きをしないため、ユーザに合わせては要件から除外できます。そうすると、動的サイトのメリットはかなり減ります。恐らく、GUIでのWebベースでのコンテンツメインテナンスなどのこの表に書かれていないモノになるでしょう。

そして、「全員に同じページを表示する」であれば、コンテンツへのテーマなどの適用はアクセス時にこだわる必要性はないになります。よって、バッチ的にサイトをコンテンツから生成する静的サイトジェネレータとなるわけです。

静的サイトジェネレータを支える要素

静的サイトジェネレータが注目された理由はそれだけではありません。一つはクライアント端末の性能向上です。例えば、昔の携帯電話のパフォーマンスと今のスマートフォンのパフォーマンスを比べてください。昔の携帯電話、フィーチャーフォン向けに開発された、CHTMLなどはかなりの仕様を削減していました、当然、クライアント側でのコード実行などは考えてすらいませんでした。しかし、今のスマートフォンはクライアント側でのモバイルコードの実行には十分であり、ECMA Script、WebAssemblyなどの支援もあります。故にコードの実行をWebサーバからクライアントに移すことも可能になりました。

故に、無理に、サーバ側で全てのコンテンツをレンダリングする必要はなくなりました、また、動的コンテンツを残すとしても、インラインフレームなどで組み込みむ手段もあります。従って、メインのコンテンツを動的に生成することは必ずしも必要なくなくなりました。

静的サイトジェネレータの限界

とはいえ、最初に上げた、「全員に同じページを表示する」という特性は無くなることはありません。

従って、静的サイトジェネレータを基盤とするBIツールであるEvidenceでは例えば、ユーザを認識してコンテンツを変えるなどは苦手です。例えば、厳密に、Need-to-Knowを実現するのは困難です。サイト自体に認証などは出来るにしても、コンテンツをユーザに合わせてレンダリングするのは困難です。

この辺のポイントを理解するのが、Evidenceを有効活用する道になります。

EvidenceによるBI入門 #003

Sun, 23 Mar 2025 00:00:00 +0900

Covid-19のダッシュボードの作成を例にしています。イメージとしては、表形式でデータが見えるようにして、時系列で合計値がチャートして見えるようにして、カレンダーヒートマップで曜日ごとの動きが見えるようにするというのを考えてみます。仮説としては人の動きに感染者は依存しているのではないかと言う仮説です。だとすれば、曜日ごとに特徴があるのではないかと言う仮説です。

流れとしては、以下のような順番になります。

プロジェクトの作成
データのインポート
クエリとビジュアリゼーションコンポーネントの配置

クエリとビジュアリゼーションコンポーネントの配置は主にMarkdownのドキュメントで行います。

プロジェクトの作成

まず、プロジェクトを作成するところから始めます。プロジェクトの作成はVisual Studio Codeから作成します。

プロジェクトの作成(1/5)

プロジェクトの作成(2/5)

プロジェクトの作成(3/5)

プロジェクトの作成(4/5)

プロジェクトの作成(5/5)

Evidenceのウェルカム画面

プロジェクトを作成すると、Evidenceのサーバを起動可能になります。Evidenceのサーバを起動すると通常はポート1313で待ち受け状態になります。そうすると、Webブラウザで開けるようになります。ウェルカム画面は以下のようになります。

Evidenceサーバの起動

Evidenceサーバの起動はVisual Studio Codeから行います。コマンドパレットから起動できます。

データのインポート

https://www.mhlw.go.jp/stf/covid-19/open-data.html から取得した、新規陽性者数の推移（日別）のデータをプロジェクトフォルダのsourcesにcovid19というディレクトリを作成して配置します。新規陽性者数の推移（日別）のデータはnewly_confirmed_cases_daily.csvというファイル名なので、newly_confirmed_cases_dailyというテーブルとして識別されます。データのインポートはEvidenceのサーバからやると、設定ファイルなどを簡単に作成できます。

データのインポート

データのインポート (1/4)

Evidenceのサーバのインポート画面ではインポート可能なデータ形式の確認ができます。 Evidenceでインポート可能なデータについてはEvidenceのWeb画面を起動したときのSettingsの中の画面で確認できる。

データのインポート (2/4)

データのインポート (3/4)

データのインポート (4/4)

現在Evidenceでインポート可能なもの

BigQuery
CSV
Databricks
DuckDB
Microsoft SQL Server
PostgreSQL
Redshift
JavaScript
Snowflake
SQLite
Trino
MotherDuck

最初のコンテンツの作成

最初のコンテンツの作成 (1/2)

次に、プロジェクトフォルダのpages/index.mdを編集します。index.mdはEvidenceのサーバに接続してデフォルトで表示されるページになります。ここのコンテンツを以下のようにします。


    ---
    title: Welcome to Evidence
    ---

    ## Covid19 のCSV確認

    ```sql covid19_10
        select *
        from covid19.newly_confirmed_cases_daily
        limit 10
    ```

    <DataTable data={covid19_10}/>

最初のコンテンツの作成 (2/2)

これにより、covid19.newly_confirmed_cases_dailyから10行取り出して表として出力されます。

EvidenceによるBI入門 #001

Thu, 20 Mar 2025 00:00:00 +0900

目的と対象読者

このドキュメントは、Windows環境を前提にEvidenceの利用方法について記述しています。Evidenceは様々な環境で稼働しますが、執筆時点での環境および設定を基準としています。

対象読者

Evidenceをはじめて利用する方
Windows環境でのセットアップ利用方法に関心のある方

前提条件

インストール済みのソフトウェア
- Visual Studio Code
- Git
- Node.js
- npm
Node.jsのインストール方法
- Scoopを利用し、執筆時点のLTSを利用しています。
Evidenceのバージョン
- バージョン 40.1.1をターゲットにしています。

Evidenceとはなにか

「Evidence」とは、Markdownで管理できるオープンソースのBI（ビジネスインテリジェンス）ツールです。具体的には、レポート、意思決定支援ツール、埋め込みダッシュボードなどのデータプロダクトを構築するためのオープンソースのフレームワークと説明されています。

Evidenceの主な特徴は以下の通りです。

コード駆動型BIツール:ドラッグ＆ドロップ式のBIツールとは異なり、コード（主にSQLとMarkdown）を使用してデータプロダクトを構築します。
Markdownで管理: Markdownファイル内でSQLクエリを記述し、コンテンツやレイアウトを管理します。
多様なデータソースに対応: データウェアハウス、フラットファイル（例：CSV）、非SQLデータソースなど、さまざまな種類のデータソースを扱うことができます。
SQLクエリの実行と結果の可視化: Markdownページに記載されたSQLステートメントに基づいてデータソースに対してクエリを実行し、その結果をグラフや表としてウェブサイトに出力できます。Markdown内で使用されるSQLはDuckDBのSQLです。
静的サイトの生成 出力は静的なウェブサイトとして生成されるため、デプロイや共有が容易です。npm run buildコマンドで静的サイトを生成し、S3などのホスティングサービスに格納して簡単に共有できます。
豊富なコンポーネント: クエリ結果に基づいて、さまざまなチャート（棒グラフなど）、表（DataTable）、大きな単一の値（BigValue）などのコンポーネントをレンダリングできます。
高度な機能: テンプレートページによる複数ページの生成、表示内容の制御のためのループやIf/Else文、クエリ結果のフィルタリング機能（Query Functions）なども備わっています。

Evidenceの適する用途

アーキテクチャなどを踏まえての説明は次回以降になりますが、Evidenceは様々な用途に利用可能です。基本的にはOn the flyのクエリーは困難なので、IoTなどの機器からのリアルタイムなダッシュボードには向きません。どちらかと言うと、日次・月次でしめるような処理が適します。従って、売り上げなどの分析が適すると思われます。

EvidenceによるBI入門 #002

Thu, 20 Mar 2025 00:00:00 +0900

基本的な準備

システム構成の概要

Evidenceのアーキテクチャ

Evidenceは基本的には、データソース、DuckDB、レンダリングエンジンという仕組みになっています。実際には更に、静的サイトジェネレータも重要な位置を示しますが、その性質からここには表現していません。以下の図にEvidenceの基本的なアーキテクチャを示します。

まず、データソースからデータが取り出され、共通のデータ形式であるParquetに変換されます。ParquetはDuckDBによって利用されます。従って、Evidenceで利用可能なデータは基本的にParquetに抽出されたデータに限定されます。よって、標準的なBIツールのようにOn the flyのクエリを動的に送出してリアルタイムなデータを反映させることは出来ません。従って、そのような要件が含まれる場合にはEvidenceは適切な選択肢ではありません。

従って、ドキュメントの流れまで含めて、アーキテクチャを図示すると以下のような形になります。

動作環境

Evidenceを動作させるためには、以下の環境が必要です。

Node.js: バージョン ≥18.13, 20, または 22 が必要です。初めてインストールする場合は、LTS（長期サポート）バージョンの利用が推奨されています。現在のNode.jsのバージョンはコマンド node -v で確認できます。
NPM (Node Package Manager): バージョン 7 以上が必要です。
Git: Gitがインストールされている必要があります。Gitがインストールされていない場合は、インストールする必要があります。GitHubへの登録も推奨されています。

これらの要件を満たすことで、Evidenceをローカル環境にインストールし、データプロダクトの構築を開始することができます。

現在のNode.jsのバージョンの確認方法

node -v

npmのバージョン確認方法

npm -v

gitのインストール方法

scoop install git

Evidenceのインストール方法

Evidenceには幾つかのインストールパターンがありますが、ダッシュボード開発時にはVisual Studio Codeと専用の拡張機能の利用が推奨されます。

本アーティクルでは、基本的にはScoopで環境構築を行っています。 scoopがインストールされている場合は以下のコマンドでnode.jsやNPMを展開できます。 scoopを利用することで、バージョンの管理、アップデートは容易になります。

scoop install nodejs-lts

なお、本アーティクル以降ではVisual Studio Codeでの構築を行っていきますので、Visual Studio CodeにEvidenceの拡張機能を導入してください。

また、これらのインストール中にエラーが生じた場合には、そのステップに応じて、ScoopやVisual Studio Code、Evidenceのドキュメントを参照してください。

システム構成の概要

ダッシュボード開発時の典型的な構成は以下のようになります。

EvidenceによるBI入門 #002.5

Thu, 20 Mar 2025 00:00:00 +0900

今回はちょっとだけ箸休め的にScoopによる環境構築を多少補足します。

本シリーズでは基本的には、環境構築はScoopを用いることを前提としています。

Scoopはコマンド一つで様々なパッケージを展開可能なツールです。

Scoopは悪い意味ではまっとうなパッケージマネージャではありません。しかし、以下の条件の元では極めて有効に働きます。

You’re a programmer/developer
You want to set up a machine without having to visit a bunch of websites, download installers and then click through each one
You’re comfortable working on the command line, especially with tools like Git
You’re familiar with UNIX tools, and you wish there were more of them on Windows
You read Hacker News and you feel like you’re ‘stuck’ on Windows and missing out on lots of cool things
You wish there was an easier way to tell other developers how to install programs (maybe your own programs)
You use Homebrew/apt-get and think, “this is awesome”.

https://github.com/ScoopInstaller/Scoop/wiki/So-What より。

Series on Grayrecord Technow Blog

Super Legend Swindler #003

Super Legend Swindler #002

Super Legend Swindler

AIモデルの注意機構を紐解く：『走れメロス』を題材にしたLLM解析

AIモデルの裏側を探る：アテンションメカニズムの可視化とは？

EvidenceによるBI入門 #003.1

静的サイトとは

静的サイトと動的サイトの差異

静的サイトが再度注目された理由

静的サイトジェネレータを支える要素

静的サイトジェネレータの限界

EvidenceによるBI入門 #003

プロジェクトの作成

プロジェクトの作成(1/5)

プロジェクトの作成(2/5)

プロジェクトの作成(3/5)

プロジェクトの作成(4/5)

プロジェクトの作成(5/5)

Evidenceのウェルカム画面

Evidenceサーバの起動

データのインポート

データのインポート

データのインポート (1/4)

データのインポート (2/4)

データのインポート (3/4)

データのインポート (4/4)

現在Evidenceでインポート可能なもの

最初のコンテンツの作成

最初のコンテンツの作成 (1/2)

最初のコンテンツの作成 (2/2)

EvidenceによるBI入門 #001

目的と対象読者

Evidenceとはなにか

Evidenceの適する用途

EvidenceによるBI入門 #002

基本的な準備

システム構成の概要

Evidenceのアーキテクチャ

動作環境

現在のNode.jsのバージョンの確認方法

最新のNode.jsへの更新方法

npmのバージョン確認方法

gitのインストール方法

Evidenceのインストール方法

システム構成の概要

EvidenceによるBI入門 #002.5