|
|
|
|
|
||
|
||
利用者情報の外部送信先を追加しました
はてなの日記 (655)
はてなロゴ日記 (32)
利用者情報の外部送信先 (5)
添付ファイル: 300x300sunDeveloper.gif 7183件 [詳細] dev_solaris_300x300_japanese.swf 6879件 [詳細]
誰もいない空間が、なぜこんなに怖くて惹かれるのか『リミナルスペース 新しい恐怖の美学』
2026-01-18
GolangのジェネリクスでWriterDB/ReaderDBの型を分ける
アプリケーションからDBを使うときに読み込み専用のノードを作ってトランザクションの不要なクエリや重いクエリを読み込み専用のノードに投げるようにすることがよくある。
アプリケーションの全体の情報を保持する構造体があるとして、Writerノード・Readerノードの両方へのコネクションプールを持つ場合、以下のような構造になると思う。
type App struct {
WriterDB *sql.DB
ReaderDB *sql.DB
}
ジェネリクスを使わないで*sql.DBの型を分ける
ReaderDBしか使わない関数に対してWriterDBを渡されたくないので、WriterDB/ReaderDBの型を分けたい。
Embeddingすると同じインターフェースを持ちながら異なる型を定義できる。
type Writer struct {
*sql.DB
} type Reader struct {
*sql.DB
} type App struct {
WriterDB *Writer
ReaderDB *Reader
} // `*Writer`は受け取れない func procForReader(db *Reader) { // ... }
WriterDB/ReaderDBの両方で使うような関数がある場合は、*sql.DBと同じメソッドを持つインターフェースを定義して引数の型にすれば*Writerと*Readerの両方を渡すことができる。
type DB interface {
Begin() (*sql.Tx, error)
BeginTx(ctx context.Context, opts *sql.TxOptions) (*sql.Tx, error) // ... } // `*Writer`と`*Reader`を受け取れる func procForDB(db DB) { // ... }
ReaderDBについては、読み込み処理しか行わないのでExec()やBegin()は禁止したい。
QueryXXX()しか持たないインターフェースを定義すれば一応、制限することはできる。
しかしそれだと、*Writerと*Reader両方を渡すことができてしまう。
type Queryer interface {
Query(query string, args ...any) (*sql.Rows, error)
} // `*Writer`も受け取れてしまう func procForReader(db Queryer) { // ... }
ジェネリクスで*sql.DBの型を分ける
…という要件をここ数日悶々と考えていて、ジェネリクスを使えばできそうなのでライブラリを書いてみた。
github.com
まずマーカーにする型を定義する。
型の実態はstruct{}でもintでも何でもいい。
type WriterDB struct{} type ReaderDB struct{} type MyDB interface {
WriterDB | ReaderDB
}
そのマーカーを使って*dbtyp.DB[T]を生成する。
writer, _ := dbtyp.New2[WriterDB](sql.Open("sqlite", "file::memory:"))
reader, _ := dbtyp.New2[ReaderDB](sql.Open("sqlite", "file::memory:"))
*dbtyp.DB[T]は*sql.DBを埋め込んでいるので同じメソッドを持つ。
type DB[T any] struct {
*sql.DB
}
*dbtyp.DB[WriterDB]と*dbtyp.DB[ReaderDB]は型が違うので当然、代入はできない。
writer = reader // COMPILE ERROR!
DBを使う関数では型パラメーターで使うDBを制限できる。
// `*dbtyp.DB[WriterDB]`は受け取れない func procForRaeder(db *dbtyp.DB[ReaderDB]) { // ... }
もし、WriterDBとReaderDBの両方を受け取りたかったら型制約MyDBを使う。
// `*dbtyp.DB[WriterDB]`と`*dbtyp.DB[ReaderDB]`を受け取れる func procForRW[T MyDB](db *dbtyp.DB[T]) { // ... }
さらに*dbtyp.DB[T]はメソッドを制限した*dbtyp.Queryer[T]を生成できる。
*dbtyp.Queryer[T]を使えば、ReaderDBに対してQueryXXX()以外のメソッドの呼び出しを禁止することができる。
func main() {
reader, _ := dbtyp.New2[ReaderDB](sql.Open("sqlite", "file::memory:"))
q := reader.Queryer()
procReader(q)
} // `*dbtyp.Queryer[WriterDB]`は受け取れない func procReader(q *dbtyp.Queryer[ReaderDB]) {
q.Query("select 1") // QueryXXX()しか呼び出せない }
既存の*sql.DB、*sql.Txとの相互運用も踏まえて、双方に互換性のあるインターフェースも用意してみた。
iface package - github.com/winebarrel/dbtyp/iface - Go Packages
type DB interface {
Begin() (*sql.Tx, error)
BeginTx(ctx context.Context, opts *sql.TxOptions) (*sql.Tx, error)
Close() error Conn(ctx context.Context) (*sql.Conn, error)
Driver() driver.Driver
Exec(query string, args ...any) (sql.Result, error)
ExecContext(ctx context.Context, query string, args ...any) (sql.Result, error)
Ping() error PingContext(ctx context.Context) error Prepare(query string) (*sql.Stmt, error)
PrepareContext(ctx context.Context, query string) (*sql.Stmt, error)
Query(query string, args ...any) (*sql.Rows, error)
QueryContext(ctx context.Context, query string, args ...any) (*sql.Rows, error)
QueryRow(query string, args ...any) *sql.Row
QueryRowContext(ctx context.Context, query string, args ...any) *sql.Row
SetConnMaxIdleTime(d time.Duration)
SetConnMaxLifetime(d time.Duration)
SetMaxIdleConns(n int)
SetMaxOpenConns(n int)
Stats() sql.DBStats
}
#golang #Database #Generics
winebarrel 2026-01-18 13:29 読者になる
GolangのジェネリクスでWriterDB/ReaderDBの型を分ける
未来予想図が破られちゃった。
結成６年目でM-1優勝、さらにその翌年も優勝、からの独立。波乱万丈の道のりを「ドタバタしながら、人に手伝ってもらいながらやってきた」というくるまさんの、現在地を聞きました。連載はとうとう明日最終回です。
神保町鼎談のおまけ
「海外の方への神保町ガイド」
タイムアウト東京さんと糸井重里による神保町鼎談の、おまけの最終回です。ほぼ日の文具好きな乗組員が、タイムアウト東京の編集メンバーに神保町のご案内をしましたよ。
ほぼ日手帳チームの募集締切は
１月20日（火）午前11時まで。
WEBディレクター、WEBデザイナー、ECサイト運営管理担当、英語版コンテンツ翻訳・制作進行担当、コンテンツ編集・ライターの５職種の募集です。まもなく締切となりますが、ぜひこの機会にご応募ください。
・関東で食べる「くず餅」は、
小麦のでんぷんを原料にしていて、
白い不透明なぷるぷるの「もちっとしたもの」である。
同じように「くず餅」と呼ばれているが、関西はちがう。
葛粉を練ってつくった透明な「ぷるぷるしたもの」である。
ぼくは、もちろん! どちらも好きだ。
で、言いたいのは、ぼくの好物のことではない。
どちらの「くず餅」も、そのまま食べるものではないのだ。
目の前にそれが出されて、どうぞお食べくださいと言われ、
そのまま「はい、いただきます」という人はいない。
黒蜜や、きなこをかけて食べるものなのだ
（葛のほうは、あんこを包んでまんじゅうにしたり）。
「くず餅」が好きだとか食べたいとか言う人でも、
実は「黒蜜で味をつけたくず餅」が好きなのである。
「おいしいね」という味のほとんどは、黒蜜だ。
しかし、そういう人でも、黒蜜だけ飲んだりはしないし、
やっぱり「くず餅が好き」と言っていいのだとは思う。
しつこく似たようなことを言うことにする。
あんみつや、みつ豆も、基本的に寒天を食べるものだ。
しかし、ご承知の通り、これも、おそらく、
寒天だけそのまま食べる人はいないだろう。
黒蜜なり、白蜜をかけて、なんならあんこも乗せて食べる。
でも、あんみつやみつ豆は、寒天を食べるおやつだ。
ついでに言うが、いちごのショートケーキの上に、
いちごが、たとえ半分にカットしたものでも、
乗ってなかったらどうだろうか?
これは「くず餅」や寒天の場合とは、少々ちがうけれどね。
本体が、主題が、名前が「くず餅」であっても、
黒蜜(そしてきなこも)がなかったら、
「だいたいの人間はあんまり食べない」のである。
人間が食べるから「くず餅」ができたのであって、
「くず餅」を定義するために「くず餅」があるのではない。
よくなにかの企画を完成させるときに、
黒蜜をかけない「くず餅」を出してしまうことがある。
というようなことを、社内で話していたのだが、
今日のこの文は、いつもより1行だけ多めに書いてみた。
なんでも、人から人になんだよ。黒蜜やいちごを忘れるなと。
気になるあいつ
今日の女房
好奇心は無限大•4年前
メンテナンス
はてなブックマークの計画メンテナンスのお知らせ（2026年1月23日(金) 深夜1:30〜3:00）
2026/01/16
猫ジャンプ
2026-01-16 · 1min
猫ジャンプ
電子ボリューム基板
2026-01-16 · 1min
電子ボリューム基板
解像度を上げる 曖昧な思考を明晰にする「深さ・広さ・構造・時間」の4視点と行動法
We’re getting things ready
Loading your experience… This won’t take long.
2026年1月 3日
土佐あかうし
子牛時代を放牧で育て、粗飼料を多給して肥育した特別な土佐あかうし「かずな」号のお肉を販売します！
あけましておめでとうございます。すっかり投稿が減ってしまっていますが、それはもうひとえに短大の業務が繁忙過ぎるからです。今年はなんとか隙間をつくり、隙間をかいくぐってブログ書きますので、どうぞよろしくお願いいたします。さて、のっけからスミマセンが、土佐あかうしの販売をはじめます。それもただのあかうしではありません。あの瓢亭さんと共同オーナーをしてきた、放牧を経験し、粗飼料を多給することで赤身のおいしさを最大化した、オーダーメイド型の育て方をした土佐あかうしです！2023年に、こんな長大なエントリを書いたことを覚えておいででしょうか。■あなたの店も土佐あかうしのオーナーに！ 四国カルストの放牧場...
続きを読む
2026年
1月
土佐あかうし(64)
アナログ、デジタル、AIの順 ～ 2025年をふりかえりながら
2025 / 12
2025年12月30日
■ 日本のAI規制体系における構造的混乱：AI事業者ガイドラインに起因する問題の連鎖
このところの日記の記載を基礎として、改めて、「AI事業者ガイドライン」と「AIセーフティに関する評価観点ガイド」をClaude Opus 4.5を用いてほぼ自動的に評価させた。繰り返しになるが、これは論文で指摘したかったことだが半年後くらいになりそうなので、早めに多くの人に認識を共有してもらうべくここに記すものである。結論は最後のターンまでスキップ。
私：日本のAI政策の問題を指摘するブログを2回書きました。この指摘に沿って「AI事業者ガイドライン」の問題点を分析してもらおうと思いますが、その前にまずこの2回分の指摘の内容を把握してください。
https://takagi-hiromitsu.jp/diary/20251216.html
https://takagi-hiromitsu.jp/diary/20251221.html
Claude：[考え中...]
2つのブログ記事を取得して内容を把握します。
[考え中...]
2つのブログ記事を取得しました。内容を整理してお伝えします。
（略）
AI事業者ガイドラインの分析に進みましょうか？
私：AI事業者ガイドラインはここにありますが、まず、「AI事業者ガイドライン（第1.1版）本編」を評価しましょう。対象PDFファイルをアップロードした方がいいですか？
https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
Claude：[考え中...]
まずはweb_fetchでPDFを取得してみます。うまくいかなければアップロードをお願いします。
[考え中...]
最新版は第1.1版（2025年3月28日公開）ですね。本編PDFを取得してみます。
[考え中...]
PDFの直接取得ができませんでした。「AI事業者ガイドライン（第1.1版）本編」のPDFをアップロードしていただけますか？
ファイルサイズが1,841KBとのことなので、問題なくアップロードできると思います。
私：（「AI事業者ガイドライン（第1.1版）本編」を添付して）
こちらがそのファイルです。先ほどのブログの趣旨に沿って、具体的に問題箇所を点を示して問題点を列挙してください。
Claude：[考え中...]
AI事業者ガイドライン（第1.1版）本編を、ブログの論点に沿って分析します。
AI事業者ガイドライン（第1.1版）本編の問題点分析
1. 根本的な問題：目的軸での類型化の欠如
問題箇所：第1部「AIとは」（9–10頁）
AIの定義は技術的観点からのみ行われており、規律目的による類型化（処遇AI/生成AI/製品AI）が存在しない。
「生成AI」の定義はある（10頁：「⽂章、画像、プログラム等を⽣成できるAIモデルにもとづくAIの総称」）
しかし「処遇AI」（個人を評価・選別・決定するAI）という概念がない
「製品AI」（物理的動作を担うAI）という概念もない
結果として、技術軸（従来AI/生成AI/高度なAI）での分類しかなく、「何を規律するのか」という目的軸での整理がない。
2. 「透明性」における混同
問題箇所：第2部C 6) 透明性 ①検証可能性の確保（18頁）
AIの判断にかかわる検証可能性を確保するため、データ量⼜はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利⽤時の⼊出⼒等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存する
ログの記録・保存にあたっては、利⽤する技術の特性及び⽤途に照らして、事故等の原因究明、再発防⽌策の検討、損害賠償責任要件の⽴証上の重要性等を踏まえて、記録⽅法、頻度、保存期間等について検討する
ここに3つの異なる目的の語彙が混在している：
語彙 本来の規律目的 対象
「AIの判断」「推論過程、判断根拠」 処遇AIの規律（決定の適切性検証） 採用判定、与信判断など
「事故等の原因究明、再発防止策」 製品AIの規律（製品安全） 自動運転車、ロボットなど
「学習プロセス」 生成AIの規律（著作権等） 文章・画像生成など
これらが「共通の指針」として一括りにされているため、どのAIに対して何のためにログを取るのかが不明確。
3. 「アカウンタビリティ」における混同
問題箇所：第2部C 7) アカウンタビリティ ①トレーサビリティの向上（20頁）
データの出所、AIシステム・サービスの開発・提供・利⽤中に⾏われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態を確保する
この「意思決定」が二義的：
「事業者の意思決定」（開発・提供・利用を決めた経緯）→ 知財紛争での立証に関係
「AIの意思決定」（AIが個人に対して行った判断）→ 処遇AIの規律に属する
文言だけでは前者の読み方も可能だが、上記6)透明性で「AIの判断」「推論過程、判断根拠等のログ」と言っている以上、実質的には処遇AI向けの規律が意図されている。しかし生成AIを含む全てのAIに「共通の指針」として適用される構造になっている。
4. 「公平性」の規律の問題
問題箇所：第2部C 3) 公平性（16–17頁）
バイアスを⽣み出す要因は多岐に渡るため、各技術要素（学習データ、AIモデルの学習過程、AI利⽤者⼜は業務外利⽤者が⼊⼒するプロンプト、AIモデルの推論時に参照する情報、連携する外部サービス等）
問題点：
「プロンプト」への言及は生成AIの技術構成要素の話
処遇AIで本来問題となる「決定に使うデータの関連性」（決定目的に関係ないデータで人を分けていないか）という観点が欠落
「差別」の定義が「特定の個⼈ないし集団への⼈種、性別、国籍、年齢、政治的信念、宗教等の多様な背景を理由とした不当で有害な偏⾒及び差別」と抽象的で、処遇AI固有の問題（決定の合理性）と生成AI固有の問題（出力のバイアス）が区別されていない
5. 「人間中心」におけるプロファイリング規定の埋没
問題箇所：第2部C 1) 人間中心 ①人間の尊厳及び個人の自律（13–14頁）
個⼈の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利⽤したプロファイリングを⾏う場合、個⼈の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利⽤し、かつ⽣じうる不利益等を慎重に検討した上で、不適切な⽬的に利⽤しない
問題点：
これは処遇AIの規律の萌芽だが、「共通の指針」の一項目に埋もれている
「関連性のないデータで人を分けていないか」という関連性原則が明示されていない
「異議申立ての途が開かれているか」「救済の仕組み」への言及がない
GDPRのような「自動処理のみに基づく決定に服さない権利」に相当する規律がない
6. 高度なAIシステムの定義の問題
問題箇所：第1部（10頁）および第2部D（25–26頁）
⾼度なAIシステム：最先端の基盤モデル及び⽣成AIシステムを含む、最も⾼度なAIシステムを指す。
問題点：
「高度な」という技術的特性での分類
EU AI Actの「高リスクAI」は用途（処遇AI的な領域）での分類だが、日本のガイドラインは技術軸
EU AI Actでは「高リスクAI」と「GPAI（汎用目的AI）」で義務の束を分けているが、このガイドラインではその区別が輸入されていない
7. 「共通の指針」という構造自体の問題
問題箇所：第2部C全体および表1（24頁）
10の指針（人間中心、安全性、公平性、プライバシー保護、セキュリティ確保、透明性、アカウンタビリティ、教育・リテラシー、公正競争確保、イノベーション）が「共通」として並べられている。
問題点：
目的の異なる規律が同一の箱に同居している
「処遇AIに必要な規律」「生成AIに必要な規律」「製品AIに必要な規律」が区別されていない
結果として、ブログで引用されていた事業者の苦情（「全体像を簡単に理解するのが困難」「項目間の対応・依存関係が不明」「辞典みたいでHowがわからない」「適切な等の漠然とした表現」）が生じる
8. 具体的な欠落事項
処遇AIの規律として本来必要だが欠落しているもの：
必要な規律 ガイドラインの状況
決定に使うデータは目的に照らして関連性があるものに限る（関連性原則） 明示的な規定なし
決定の根拠を本人に示す（説明義務） 「透明性」に埋もれている
異議申立て・再審査の仕組み 規定なし
自動処理のみに基づく決定に服さない権利 規定なし
処遇AIに特化した監査・モニタリング 「共通」の中に埋没
まとめ：問題の構造
【現状のガイドライン】
┌─────────────────────────────────┐
│ 「共通の指針」（10項目） │
│ ・人間中心 │
│ ・安全性 ← 製品安全の語彙が混入 │
│ ・公平性 ← 生成AI/処遇AI混在 │
│ ・プライバシー保護 │
│ ・セキュリティ確保 │
│ ・透明性 ← 3つの目的が混在 │
│ ・アカウンタビリティ ← 同上 │
│ ・教育・リテラシー │
│ ・公正競争確保 │
│ ・イノベーション │
└─────────────────────────────────┘
↓
全てのAIに「共通」として適用
↓
「何のために何をすべきか」が不明確
【本来あるべき構造】
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 処遇AI │ │ 生成AI │ │ 製品AI │
│ │ │ │ │ │
│・関連性原則 │ │・出力管理 │ │・製品安全 │
│・説明義務 │ │・著作権対応 │ │・事故調査 │
│・異議申立て │ │・悪用防止 │ │・原因究明 │
│・救済 │ │・表示義務 │ │・再発防止 │
└──────────┘ └──────────┘ └──────────┘
ブログの指摘どおり、EUから「キーワード」だけを輸入し、「区別」を輸入していない構造が、このガイドラインの根本的な問題です。
私：（「AI事業者ガイドライン（第1.1版）別添」を添付して）
次に「別添」も見てみましょう。ファイルはこちらです。
Claude：[考え中...]
別添のPDFを確認します。ファイルサイズが大きい（6,361KB）ので、まず構造を把握してから詳細を見ていきましょう。
[考え中...]
PDFの生データが表示されてしまいました。テキスト抽出を試みます。
[考え中...]
別添の構造が見えてきました。続けてリスクの例やAIガバナンスの構築部分を確認します。
[考え中...]
別添の内容をさらに詳しく確認します。特にリスクの分類と具体的な実践例を見ていきましょう。
[考え中...]
リスクの分類構造が見えました。次に透明性・アカウンタビリティの実践例を確認します。
[考え中...]
透明性・検証可能性の具体的な実践例を確認します。
[考え中...]
リスク例と指針のマッピング部分を確認します。
[考え中...]
人材採用AIなどの事例がどのように扱われているか確認します。
[考え中...]
プロファイリングに関する記述を詳しく確認します。
[考え中...]
AIエージェントに関する記述を確認します。
[考え中...]
これで別添の内容を十分に確認できました。分析結果をまとめます。
AI事業者ガイドライン別添（付属資料）の問題点分析
1. リスク分類の軸が目的軸ではなく技術軸・発生段階軸
問題箇所：表3「AIによるリスク例の体系的な分類案」（別添1, 19頁相当）
リスクは以下のように分類されている：
大分類 中分類
技術的リスク 学習及び入力段階のリスク / 出力段階のリスク / 事後対応段階のリスク
社会的リスク 倫理・法に関するリスク / 経済活動に関するリスク / 情報空間に関するリスク / 環境に関するリスク
ブログの指摘との対比：
「処遇AI」「生成AI」「製品AI」という目的軸での分類がない
結果として、同じ「バイアスのある出力」というリスク名で、処遇AI（採用差別）と生成AI（偏った文章生成）が同一視される
2. 処遇AI固有の問題が「共通の指針」に埋没
問題箇所：リスク例と指針のマッピング（表4）
例えば「バイアスのある出力、差別的出力」への対策として挙げられているのは：
3）公平性：「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」
欠落している視点：
「決定に使うデータは目的に照らして関連性があるものに限る」（関連性原則）
「異議申立て・再審査の仕組み」
「自動処理のみに基づく決定に服さない権利」
採用AI差別の例（868行目）で「女性を差別するという機械学習面の欠陥」と記述されているが、これは「性別という関係のない情報で人を分けた」という関連性原則違反の問題であり、単なる「バイアス」問題ではない。
3. プロファイリングの記述が分散・埋没
問題箇所：別添4「AI提供者向け」（7535-7565行目付近）
プロファイリングの問題点として以下が列挙されている：
プロファイリング結果が事実と異なることにより誤った判断が下されること
個人の特定の特徴のみがプロファイリングで用いられることにより、個人が過小又は過大に評価されてしまうこと
特定の個人又は集団に対する不当な差別を助長すること
問題点：
これらは処遇AIの核心的問題だが、「AI提供者向け」の「1）人間中心」の解説の一部に埋もれている
「プロファイリングに関する最終提言」（パーソナルデータ+α研究会）への参照はあるが、ガイドライン本体の構造に反映されていない
EU AI Actの「高リスクAI」のような明確な規律カテゴリになっていない
4. 透明性・検証可能性の混同
問題箇所：D-6「検証可能性の確保」（5607行目付近）
「説明可能性・解釈可能性を高めるための手法」として以下が列挙：
単純なAIモデルの使用（ロジスティック回帰、決定木等）
局所的な説明手法（LIME等）
SHAP値
特徴の寄与度可視化
AIモデル内部の解析
RAGの導入による出力根拠の透明性向上
問題点：これらは技術的な機械学習モデルの解釈手法であり、3つの異なる目的が混在：
手法 本来の適用対象
LIME、SHAP値、特徴重要度 処遇AI（なぜこの人にこの判断をしたか）
RAGによる出典明示 生成AI（どこから情報を得たか）
ログの記録・保存 製品AI（事故原因究明）または全般
5. AIエージェントのリスク記述の問題
問題箇所：脚注16（1528行目付近）
AIエージェントの登場により、事故等の安全性面のリスクや過度な依存、労働者の失業等のリスクが複雑化・深刻化する可能性があることにも留意する必要がある。
ブログの指摘との対比：これはまさにブログで批判されていた「AIエージェントのリスク一覧」の問題：
「判断根拠の不透明性」（処遇AI問題）
「誤情報拡散」（生成AI問題）
「事故等の安全性面のリスク」（製品AI問題）
「ツール悪用」（セキュリティ問題）
「過度な依存」（人間とAIの関係問題）
が同列に並べられている。
6. 具体的事例の分析における問題
問題箇所：採用AI、与信AI、クレジットカード限度額の事例>
事例 ガイドラインでの扱い 本来必要な分析
採用AIの女性差別 「バイアスのある出力」（技術的リスク） 関連性原則違反（性別は採用に関係ない）
クレジットカード限度額の男女差 「ブラックボックス化」「判断に関する説明の不足」 処遇AIの説明義務・異議申立て権
与信判断AI 「AIを活用したプロファイリング」への配慮 与信決定の関連性・救済の仕組み
7. 構造的問題のまとめ
【別添の現状】
┌─────────────────────────────────────┐
│ リスク分類：技術的リスク / 社会的リスク │
│ ↓ │
│ 対策：「共通の指針」10項目へマッピング │
│ ↓ │
│ 実践：LIME、SHAP値、RAG、ログ記録... │
│ （技術手法の羅列） │
└─────────────────────────────────────┘
↓
「何のAIに対して何のために何をすべきか」が不明確
【本来あるべき構造】
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 処遇AIリスク │ │生成AIリスク │ │製品AIリスク │
├──────────┤ ├──────────┤ ├──────────┤
│・採用差別 │ │・偽情報生成 │ │・自動運転事故 │
│・与信差別 │ │・著作権侵害 │ │・ロボット暴走 │
│・保険差別 │ │・なりすまし │ │・医療機器誤動作 │
├──────────┤ ├──────────┤ ├──────────┤
│【必要な規律】 │ │【必要な規律】 │ │【必要な規律】 │
│・関連性原則 │ │・出力管理 │ │・製品安全 │
│・説明義務 │ │・表示義務 │ │・事故調査 │
│・異議申立て │ │・著作権対応 │ │・原因究明 │
│・救済の仕組み │ │・悪用防止 │ │・再発防止 │
└──────────┘ └──────────┘ └──────────┘
結論：別添は本編の問題を増幅している
本編で「共通の指針」として一括りにされた問題が、別添では具体的な事例や技術手法として展開されているが、目的軸での区別がないまま具体化されているため：
事業者は「自社のAIがどの規律に服すべきか」を判断できない
技術手法（LIME、SHAP等）が羅列されているが、どのAIにどの手法が必要かが不明確
処遇AI固有の規律（関連性原則、異議申立て、救済）が「プロファイリングへの配慮」として埋もれている
結果として、ブログで引用された事業者の苦情（「辞典みたいでHowがわからない」）が生じる
私：「5. AIエージェントのリスク記述の問題」は、ブログで取り上げた「AIガバナンス検討会（第28回）令和7年12月2日」の件はこの資料より未来の話なので未反映だったわけですが、予告的に脚注に記載があったわけですね。ここは深掘りは不要です。
「6. 具体的事例の分析における問題」について深掘りしてください。
Claude：[考え中...]
具体的事例の記述を詳しく確認します。
[考え中...]
採用AIサービス（リクナビ事件と思われる）の事例周辺をもう少し確認します。
[考え中...]
リスクと指針のマッピングにおける「バイアスのある出力」への対応と、公平性の具体的手法を確認します。
[考え中...]
「異議申立て」「救済」「不服」「再審査」に関する記述を検索します。
[考え中...]
本編で言及されていた「プロファイリング」について、別添でどのように解説されているか確認します。
[考え中...]
「関連」「関係のある」「目的に照らし」などの観点からの記述を確認します。
[考え中...]
EU AI Actの高リスクAIについての言及を確認します。
[考え中...]
リクナビ的事例（内定辞退予測）についてもう少し確認します。
具体的事例の分析における問題：深掘り
事例1：採用AI差別（Amazon的事例）
ガイドラインの記述（別添 868–871行目）：
IT企業が自社でAI人材採用システムを開発したが、女性を差別するという機械学習面の欠陥が判明した。この原因としては、学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識したためといわれている。
ガイドラインでの分類：
リスク分類：「技術的リスク」→「出力段階のリスク」→「バイアスのある出力、差別的出力」
対策指針：「3）公平性」→「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」
ガイドラインの問題認識： 「学習データの偏り（男性が多かった）」→「AIが男性を好むと学習」→「バイアスのある出力」
本来必要な分析（ブログの視点）：
観点 本来の問題
関連性原則の欠如 「性別」は採用判断の目的（職務遂行能力の評価）に関連性がない情報。学習データにおいて「性別」と「採用結果」の相関があったとしても、それを判断材料に使うこと自体が問題。バイアス「除去」ではなく、そもそも使ってはいけない情報。
問いの立て方の誤り 「どうすれば性別バイアスを除去できるか」ではなく、「採用判断に関連性のある情報は何か」を問うべき
救済の欠如 不採用となった人が「なぜ自分は落ちたのか」を問い、「性別が理由だったなら再審査を」と求める権利の保障が言及されていない
事例2：クレジットカード限度額差別（Apple Card的事例）
ガイドラインの記述（別添 905–911行目）：
とあるクレジットカードにおいて、同じ年収を有する男性及び女性に対して、女性の方が利用限度額が低いとの報告がSNS上で広がった。この問題に対し、金融当局が調査を実施し、クレジットカードを提供した企業に対してアルゴリズムの正当性の証明を求めた。しかし、企業はアルゴリズムの具体的な機能及び動作について説明することができなかった
ガイドラインでの分類：
リスク分類：「技術的リスク」→「事後対応段階のリスク」→「ブラックボックス化、判断に関する説明の不足」
対策指針：「6）透明性」→「検証可能性の確保」「関連するステークホルダーへの情報提供」
ガイドラインの問題認識：
「アルゴリズムがブラックボックス」→「説明できなかった」→「透明性の問題」
本来必要な分析（ブログの視点）：
観点 本来の問題
問題の本質の取り違え 問題は「説明できなかった」ことではなく、「同じ年収なのに性別で限度額が異なった」こと自体。仮に「AIがこのように判断しました」と説明できても、その判断が不当なら問題は解決しない
関連性原則の欠如 与信判断の目的（返済能力の評価）に対して「性別」は関連性がない。「性別」を直接使わなくても、それと相関する代理変数で差が生じているなら同じ問題
異議申立て権の欠如 限度額が低く設定された人が「なぜ自分は低いのか」を問い、理由が不当なら是正を求める権利の保障が言及されていない
「透明性」の履き違え 「透明性」を「アルゴリズムの説明」と捉えているが、処遇AIで必要なのは「この人に対するこの判断の根拠」の提示
事例3：内定辞退予測サービス（リクナビ的事例）
ガイドラインの記述（別添 922–926行目）：
人材採用にAIを用いるサービスにて、選考離脱及び内定辞退の可能性をAIにより提供した際、学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかったこと等、透明性を欠く個人情報の利用が問題視され、サービスが廃止されることとなった
ガイドラインでの分類：
リスク分類：「社会的リスク」→「倫理・法に関するリスク」→「個人情報の不適切な取扱い」
対策指針：「4）プライバシー保護」→「プライバシー保護のための仕組み及び対策の導入」
ガイドラインの問題認識：
「説明が不明瞭」「同意なく第三者提供」→「個人情報の不適切な取扱い」→「プライバシー問題」
本来必要な分析（ブログの視点）：
観点 本来の問題
関連性原則の根本的欠如 Webサイト閲覧行動・クリック履歴は、当該学生の職務遂行能力や適性とは無関係。「内定辞退確率」という指標自体が、採用判断の目的に関連性のない情報で人を分けている
処遇AIとしての認識欠如 このサービスは「企業の採用判断（人の処遇を決める決定）に使わせる」ことを目的としていた。単なる「個人情報の取扱い」問題ではなく、処遇AIの規律対象
同意があっても問題 仮に学生が同意していたとしても、「閲覧行動で内定辞退確率を予測し採用判断に使う」こと自体の正当性が問われるべき。同意は免罪符にならない
問題の矮小化 「透明性」「プライバシー」の問題に矮小化することで、「そもそもそのようなスコアリングで人を分けてよいのか」という本質的問いが回避されている
事例4：与信判断AI（7分で融資）
ガイドラインの記述（別添 4741–4770行目付近）：
顧客の行動を分析した上で、AIが数分間で与信判断を行い、顧客に最適な融資提案を行う完全自動化ソリューション
【実装手段】Fairness by Designの活用：設計段階からステークホルダーの意見を取り入れる参加型デザイン手法を用いて、ローン審査の判断基準となる収入、勤務先、取引履歴等の属性及び公平性に関わる年齢、性別、国籍等の属性の重みを数値化することで、ビジネス上の要件及び公平性をバランスさせたAIモデルの開発を可能とし…
ガイドラインでの扱い：
「コラム13：データ前処理・学習時におけるデータに含まれるバイアスへの配慮についての事例」として紹介
Fairness by Design」「交差バイアス軽減アルゴリズム」等の技術的手法で対応
ガイドラインの問題認識：
「センシティブ属性（年齢、性別、国籍等）」→「交差バイアスも考慮」→「公平性をバランス」
本来必要な分析（ブログの視点）：
観点 本来の問題
「バランス」という発想の危うさ 「ビジネス上の要件及び公平性をバランス」という発想自体が問題。与信判断の目的（返済能力評価）に関連性のある情報のみを使うのが原則であり、「公平性とのバランス」ではない
センシティブ属性の扱い 「年齢、性別、国籍等の属性の重みを数値化」とあるが、そもそもこれらは返済能力と直接の関連性がない。「重みを調整する」のではなく「使わない」が正しい対応
異議申立て・救済の欠如 「完全自動化ソリューション」とあるが、融資を断られた人が理由を問い、不当なら再審査を求める権利への言及がない
「透明性」の方向性 技術的な「説明可能性」（LIME、SHAP値等）に焦点が当たっているが、融資申込者が必要とするのは「なぜ自分は断られたのか」の具体的説明
問題の構造：なぜガイドラインはこうなるのか
【ガイドラインの分析枠組み】
事例 → 「技術的問題」として認識
↓
「バイアス」「ブラックボックス」「個人情報」等のキーワードで分類
↓
「共通の指針」（公平性、透明性、プライバシー等）にマッピング
↓
技術的手法（バイアス除去、説明可能AI、匿名化等）を適用
【本来必要な分析枠組み】
事例 → 「何のためのAIか」で分類
↓
処遇AI（人の処遇を決定）であれば：
↓
① 決定目的は何か
② その目的に関連性のある情報は何か
③ 関連性のない情報で人を分けていないか
④ 決定の根拠を本人に示せるか
⑤ 異議申立て・再審査の途はあるか
⑥ 救済の仕組みはあるか
具体的な欠落事項のまとめ
ガイドラインで言及されていること ガイドラインで欠落していること
学習データのバイアス 関連性原則（目的に関連ある情報のみ使用）
センシティブ属性の除去・調整 そもそも使ってはいけない情報の明示
アルゴリズムの説明可能性（LIME、SHAP等） 「この人に対するこの判断」の説明義務
同意に基づく個人情報の取扱い 同意があっても許されない処遇決定の範囲
事後的な被害救済 異議申立て権・再審査請求権
技術的な公平性指標（demographic parity等） 処遇決定の正当性の実体的基準
ブログの視点からの根本的批判
これらの事例分析の問題は、ブログで指摘された構造的問題の具体的な現れです：
「処遇AI」という概念がないため、「人の処遇を決めるAI」に固有の規律が設計されていない
「関連性原則」が輸入されていないため、「バイアス除去」という技術的対処に終始し、「そもそも使ってはいけない情報」という発想がない
EU AI Actの「高リスクAI」の規律（採用、与信、保険等における説明義務、人間の監視、異議申立て権等）が参照されていない
事例を「技術的リスク」として処理することで、「なぜそのようなAIを使うのか」「どのような決定が許されるのか」という規範的問いが回避されている
私：（「チェックリスト及び具体的なアプローチ検討のためのワークシート（別添7A, 7B, 7C）」を添付して）
では続いて「「AI事業者ガイドライン（第1.0版）」チェックリスト及び具体的なアプローチ検討のためのワークシート（別添7A, 7B, 7C）」を見てみましょう。ファイルはこちらです。
Claude：[考え中...]
このチェックリストとワークシートを詳細に分析します。特に採用AIの記載例が含まれているので、処遇AIの観点から問題点を検討します。
別添7（チェックリスト・ワークシート）の分析
1. チェックリスト（別添7A・7B）の構造的問題
別添7A「全主体向け」チェック項目：
☐ 人間中心
☐ 安全性
☐ 公平性
☐ プライバシー
☐ セキュリティ
☐ 透明性
☐ アカウンタビリティ
☐ AIガバナンス・プライバシーポリシー
別添7B「高度なAIシステム向け」チェック項目：
☐ AIライフサイクル全体のリスク評価・軽減
☐ 脆弱性・インシデント対応
☐ 能力・限界・使用領域の公表
☐ 情報共有・インシデント報告
☐ AIガバナンス・リスク管理方針
☐ セキュリティ管理
☐ 電子透かし・コンテンツ認証
☐ リスク軽減研究への投資
☐ 世界課題への貢献
☐ 技術規格の開発推進
☐ データ入力措置・知的財産保護
☐ デジタルリテラシー向上
問題点：
観点 EU AI Act高リスクAI 日本のチェックリスト
AI種類による区別 用途別（採用、与信、司法等）に高リスク指定 「高度なAI」＝技術的先進性で区別
処遇AI固有項目 説明義務、人間監視、異議申立て権 なし（共通の指針のみ）
対象者の権利 自動処理決定に服さない権利 なし
2. ワークシート採用AI記載例の詳細分析
ワークシートには「エントリーシートの文章で、応募者に対し合否を判断する採用AI (XGBoost)の例」が記載されています。これは処遇AIの典型例です。
記載されている対応策
AI開発者の対応例：
・応募者の属性(特定の国/地域/人種/性別/年齢)による不公平な予測結果が
含まれる可能性あり
→ AIモデル開発・アップデート時に学習データにおける著しい偏り
(特定の国/地域/人種/性別/年齢)がないかを評価する
→ AIモデルの学習時に重要性の高い特徴量をレビューして著しい偏りがないかを評価する
AI提供者の対応例：
・採用AIの提供において、AI利用者が最終判断(応募者の合否)を行えるようにする
(Human-in-the-loop)
・採用AIが起こし得る統計的差別について認識し、対応策を策定する
AI利用者の対応例：
・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨を
エントリーシート記入依頼時に通知する
・申込者からの問合せメールフォームを設置し、対応を行う
欠落している観点（ブログの視点から）
本来必要な規律 ワークシートの記載 問題点
関連性原則 なし 「属性のバイアス評価」はあるが、「そもそも採用判断の目的に照らしてどの情報を使うべきか」という問いがない
決定目的の明確化 「採用AIの利用目的・範囲を明確にした利用者向けのマニュアル」 採用担当者向けであり、「何を評価するAIか」の定義が応募者に示されない
応募者への説明義務 「判断根拠情報及び類似する判断事例を出力する」 これは採用担当者向けであり、応募者への説明ではない
異議申立て権 「申込者からの問合せメールフォームを設置」 単なる問い合わせ窓口であり、「不採用理由の開示請求」「再審査請求」の権利ではない
自動処理決定に服さない権利 「Human-in-the-loop」 事業者の配慮として位置づけられており、応募者の権利として保障されていない
3. 具体的な問題箇所
問題箇所①：1)① 人間の尊厳及び個人の自律
ワークシートの記載：
c. 個人の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利用したプロファイリングを行う場合、個人の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利用し、かつ生じうる不利益等を慎重に検討した上で、不適切な目的に利用していないか？
問題点：
「不適切な目的」が何かが定義されていない
関連性原則（決定目的に関連する情報のみを使用）が明示されていない
「慎重に検討」という主観的基準のみ
本来あるべき問い：
採用判断に使用するデータは、職務遂行能力の評価という目的に照らして関連性があるか？性別・人種・年齢等の関連性のない属性（またはその代理変数）で応募者を分類していないか？
問題箇所②：3)① バイアスへの配慮
ワークシートの記載：
a. 不適切なバイアスを生み出す要因は多岐に渡るため、各技術要素（学習データ、モデルの学習過程…）及びAI利用者の振る舞いを含めて、公平性の問題となりうるバイアスの要因となるポイントを特定しているか？
採用AI記載例の対応：
・AIモデル開発・アップデート時に学習データにおける著しい偏り(特定の国/地域/人種/性別/年齢)がないかを評価する
問題点：
「バイアスの除去・軽減」という技術的対処に終始
そもそも使ってはいけない情報という発想がない
「著しい偏り」の基準が不明確
本来あるべき問い：
性別・人種・年齢等は採用判断の目的（職務遂行能力の評価）に関連性がないため、これらの情報（及びこれらと相関する代理変数）を学習・推論に使用していないか？
問題箇所③：6)① 検証可能性の確保
ワークシートの記載：
a. AIの判断にかかわる検証可能性を確保するため、データ量又はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利用時の入出力等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存しているか？
採用AI記載例の対応：
・(AI利用者の最終判断に向けて)AIモデルから判断根拠情報及び類似する判断事例を出力する
問題点：
ログ記録・判断根拠出力は事業者内部向け
応募者に対する説明義務として位置づけられていない
「事故の原因究明、再発防止策の検討、損害賠償責任要件の立証」が目的とされており、決定対象者の権利保護が目的ではない
本来あるべき問い：
不採用となった応募者から理由の開示を求められた場合に、「あなたの応募書類はこの基準でこのように評価された」と説明できる仕組みがあるか？
問題箇所④：7)② 共通の指針の対応状況の説明（AI利用者向け）
ワークシートの記載：
c. 当該AIの出力結果を特定の個人又は集団に対する評価の参考にする場合は、AIを利用している旨を評価対象となっている当該特定の個人又は集団に対して通知し、当ガイドラインが推奨する出力結果の正確性、公正さ、透明性等を担保するための諸手続きを遵守し、かつ自動化バイアスも鑑みて人間による合理的な判断のもと、評価の対象となった個人又は集団からの求めに応じて説明責任を果たしているか？
採用AI記載例の対応：
・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨をエントリーシート記入依頼時に通知する
・申込者からの問合せメールフォームを設置し、対応を行う
問題点：
「通知」＝AIを使っていることの告知のみ
「説明責任」＝問い合わせ対応窓口の設置のみ
具体的な説明内容（なぜ不採用なのか）が規定されていない
異議申立て・再審査の権利への言及がない
本来あるべき規定：
不採用者に対し、求めに応じて決定理由を開示する義務
決定に異議がある場合の再審査請求権
自動処理のみに基づく決定に服さない権利の告知
4. 構造的問題のまとめ
【ワークシートの発想】
採用AI開発 → 「バイアスがないかチェック」
→ 「ログを記録」
→ 「Human-in-the-loop」
→ 「AIを使っていると通知」
→ 「問い合わせ窓口設置」
↓
「事業者の配慮事項」として整理
応募者は「ステークホルダー」の一つとして言及
【本来あるべき発想】
採用AI ＝ 処遇AI（人の処遇を決定するAI）
↓
応募者には以下の「権利」がある：
① 関連性のある情報のみで評価される権利
② 決定理由の説明を受ける権利
③ 異議を申し立て再審査を求める権利
④ 自動処理のみに基づく決定に服さない権利
↓
事業者には以下の「義務」がある：
① 目的に関連ある情報のみを使用する義務
② 決定理由を説明する義務
③ 異議申立て・再審査の仕組みを設ける義務
④ 人間の実質的関与を確保する義務
5. 採用AI記載例で欠落している項目一覧
処遇AI固有の規律 ワークシートの対応 評価
決定目的の明確化と公表 「利用目的・範囲を明確にした利用者向けマニュアル」 ✗ 応募者向けではない
関連性原則の遵守 なし ✗ 完全欠落
センシティブ属性の不使用 「バイアス評価」「偏りがないか評価」 △ 技術的対処のみ
応募者への決定理由説明 「判断根拠情報を出力」（採用担当者向け） ✗ 応募者向けではない
異議申立て権 「問い合わせメールフォーム設置」 ✗ 異議申立て権ではない
再審査請求権 なし ✗ 完全欠落
自動処理決定に服さない権利 「Human-in-the-loop」 △ 事業者配慮であり権利ではない
救済の仕組み なし ✗ 完全欠落
結論
このワークシートは処遇AIの典型例である採用AIを題材としながら、処遇AI固有の規律が設計されていないという問題を如実に示しています。
「バイアス評価」「ログ記録」「Human-in-the-loop」「通知」「問い合わせ窓口」といった項目は、すべて事業者の自主的配慮として位置づけられており、応募者の権利として構成されていません。
ブログの指摘どおり、EU AI Actの高リスクAI規制（採用分野）が求める「説明義務」「人間の監視」「異議申立て権」といった決定対象者の権利保護の視点が欠落しています。
私：資料は以上です。全体を通して、現在の混乱ぶりが「AI事業者ガイドライン」にあることを論述してください。
Claude：[考え中...]
AI事業者ガイドラインに起因する混乱の構造
1. 混乱の核心：目的類型なき規制体系
日本のAI事業者ガイドラインが引き起こしている混乱の根源は、AIを目的別に類型化していないことにあります。
ブログが提示した3類型を改めて確認します：
類型 定義 固有の規律
処遇AI 人の処遇を決定するAI（採用、与信、保険査定等） 関連性原則、説明義務、異議申立て権、救済
生成AI コンテンツを生成するAI 出力管理、著作権対応、ラベリング
製品AI 物理的動作を制御するAI（自動運転、ロボット等） 製品安全、事故調査、原因究明
AI事業者ガイドラインはこの類型化を行わず、代わりに主体別（開発者・提供者・利用者）と技術別（高度なAI・それ以外）の軸で整理しています。その結果、「このAIは何のためのものか」という最も本質的な問いが抜け落ち、規制の焦点が定まらない事態を招いています。
2. 「共通の指針」という構造的誤謬
ガイドラインは10項目の「共通の指針」を全AIに適用する構造をとっています：
1) 人間中心
2) 安全性
3) 公平性
4) プライバシー保護
5) セキュリティ確保
6) 透明性
7) アカウンタビリティ
8) 教育・リテラシー
9) 公正競争確保
10) イノベーション
この「共通の指針」という発想自体が混乱の源泉です。なぜなら、同じ言葉がAI類型によって全く異なる意味を持つからです。
「透明性」の意味の分裂
AI類型 「透明性」の本来の意味
処遇AI この人に対するこの決定の理由を本人に説明できること
生成AI 出力の情報源・生成過程を示せること（RAG、来歴）
製品AI 事故発生時に動作ログを遡って原因を究明できること
ガイドラインはこれらを区別せず、「透明性」として一括りにしています。別添の「D–6 検証可能性の確保」（5607–5750行目）では、LIME、SHAP、RAG、ログ記録が同列に並べられています。技術者は「どの手法をいつ使うべきか」がわからず、経営者は「何をすれば透明性を確保したことになるのか」が判断できません。
「公平性」の意味の分裂
AI類型 「公平性」の本来の意味
処遇AI 決定目的に関連性のある情報のみで判断すること（関連性原則）
生成AI 出力にステレオタイプや偏見が含まれないこと
製品AI 特定の属性の人にとって危険でないこと（アクセシビリティ）
ガイドラインは「公平性」を「バイアスへの配慮」として技術的に処理しています。ワークシートの採用AI記載例では「学習データにおける著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」とありますが、これは技術的なバイアス除去であって、そもそも性別や人種を採用判断に使ってはならないという関連性原則ではありません。
3. 具体的事例分析における混乱
ガイドライン別添に記載された具体的事例は、この構造的欠陥を如実に示しています。
事例1：採用AI差別（Amazon的事例）
ガイドラインの分析：
学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識した
→ リスク分類：「バイアスのある出力」
→ 対策：「データに含まれるバイアスへの配慮」
本来の分析：
この問題の本質は「学習データの偏り」ではなく、性別という採用目的に無関係な情報でスコアリングしたことです。仮に男女比が50:50のデータで学習しても、性別と相関する特徴量で判断していれば同じ問題が生じます。必要なのは「バイアス除去」ではなく「関連性原則の遵守」です。
事例2：クレジットカード限度額差別（Apple Card的事例）
ガイドラインの分析：
企業はアルゴリズムの具体的な機能及び動作について説明することができなかった
→ リスク分類：「ブラックボックス化、判断に関する説明の不足」
→ 対策：「検証可能性の確保」「関連するステークホルダーへの情報提供」
本来の分析：
問題は「説明できなかった」ことではなく、同じ年収なのに性別で限度額が異なったことです。仮にアルゴリズムを完璧に説明できても、その説明が「性別で差をつけました」であれば問題は解決しません。必要なのは「透明性」ではなく「関連性原則の遵守」と「異議申立て・救済の仕組み」です。
事例3：内定辞退予測サービス（リクナビ的事例）
ガイドラインの分析：
学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかった
→ リスク分類：「個人情報の不適切な取扱い」
→ 対策：「プライバシー保護のための仕組み及び対策の導入」
本来の分析：
問題は「説明不明瞭」「同意なき第三者提供」ではありません。Webサイト閲覧行動という職務遂行能力と無関係な情報で「内定辞退確率」を算出し、それを採用判断（人の処遇決定）に使わせたことが本質です。仮に完璧な説明と同意があっても、「閲覧行動で人を分ける」こと自体の正当性が問われるべきです。
4. チェックリスト・ワークシートの無力化
別添7のチェックリストとワークシートは、この構造的欠陥を実務レベルで増幅しています。
チェックリスト（別添7A）の問題
全主体向けチェックリストは以下の項目を列挙しています：
☐ 潜在的なバイアスをなくすよう留意し、それでも回避できないバイアスがあることを認識しつつ、回避できないバイアスが人権及び多様な文化を尊重する公平性の観点から許容可能か評価しているか？
この問いに対して、採用AIを運用する企業は何をすればよいのでしょうか。「バイアスを評価した」と言えば足りるのか、どのような基準で「許容可能」と判断するのか、判断の責任は誰が負うのか——いずれも不明確です。
EU AI Actの高リスクAI規制であれば、採用AIには以下の具体的義務が課されます：
決定対象者への説明義務（Article 86）
人間の実質的監視義務（Article 14）
決定に対する異議申立ての権利保障
日本のチェックリストには「☐ 異議申立ての仕組みがあるか」という項目すら存在しません。
ワークシート採用AI記載例の問題
ワークシートは採用AIを題材に具体的な対応例を示していますが、処遇AIとしての核心的規律が欠落しています：
処遇AI固有の規律 ワークシートの対応
関連性原則 なし
応募者への決定理由説明 「判断根拠情報を出力」（採用担当者向け）
異議申立て権 「問い合わせメールフォーム設置」
再審査請求権 なし
自動処理決定に服さない権利 「Human-in-the-loop」（事業者配慮）
救済の仕組み なし
特に深刻なのは、「判断根拠情報を出力する」という対応が採用担当者向けであり、応募者本人に説明するという発想がないことです。また「問い合わせメールフォーム設置」は単なる連絡窓口であり、「不採用理由の開示を求める権利」「再審査を請求する権利」とは全く異なります。
5. 混乱が生まれる構造
以上の分析から、混乱の構造を図示します：
【AI事業者ガイドラインの構造】
┌─AI開発者─┐
│ │
全AI ────┼─AI提供者─┼──→ 共通の指針（10項目）
│ │ ・透明性
└─AI利用者─┘ ・公平性
・安全性
・...
↓
技術的対応
・LIME, SHAP
・バイアス評価
・ログ記録
・...
↓
【結果】
・何をすればよいかわからない
・どのAIに何が必要かわからない
・決定対象者の権利が見えない
【本来あるべき構造】
┌────処遇AI────┐ ┌────生成AI────┐ ┌────製品AI────┐
│採用・与信・保険 │ │テキスト・画像 │ │自動運転・ロボ │
├───────────┤ ├───────────┤ ├───────────┤
│【義務】 │ │【義務】 │ │【義務】 │
│・関連性原則 │ │・出力管理 │ │・製品安全基準 │
│・説明義務 │ │・著作権対応 │ │・事故報告 │
│・異議申立対応 │ │・ラベリング │ │・原因究明 │
├───────────┤ ├───────────┤ ├───────────┤
│【権利】 │ │【権利】 │ │【権利】 │
│・説明を受ける │ │・AI生成物と │ │・安全な製品 │
│・異議を申立て │ │ 知る権利 │ │ を使う権利 │
│・救済を求める │ │ │ │・事故時賠償 │
└───────────┘ └───────────┘ └───────────┘
6. 政策的帰結：AIガバナンス検討会の混乱
この構造的欠陥は、ブログが指摘した「AIガバナンス検討会（第28回）」の議論にも現れています。検討会資料では以下のリスクが同列に並べられています：
判断根拠の不透明性（処遇AIの問題）
誤情報の拡散（生成AIの問題）
安全性・事故リスク（製品AIの問題）
ツールの悪用（セキュリティの問題）
過度の依存（人間-AI関係の問題）
これらは異なる目的のAIに対する異なる規律であるにもかかわらず、「AIエージェントのリスク」として一括りにされています。その結果、「どのリスクにどう対応するか」という議論が深まらず、「リスクがある」という認識の共有で終わってしまいます。
7. 結論：ガイドラインの根本的再設計の必要性
AI事業者ガイドラインに起因する混乱を解消するためには、以下の根本的再設計が必要です：
(1) 目的類型の導入
「共通の指針」という発想を改め、AI目的別に固有の規律を設計する：
処遇AI：関連性原則、説明義務、異議申立て権、救済の仕組み
生成AI：出力管理、著作権対応、AI生成物の表示
製品AI：製品安全基準、事故報告、原因究明義務
(2) 権利主体の明確化
「ステークホルダーへの配慮」という事業者目線を改め、決定対象者・利用者・第三者の権利として構成する：
処遇AIの決定対象者：説明を受ける権利、異議を申し立てる権利、救済を求める権利
生成AIの利用者：AI生成物と知る権利
製品AIの利用者・第三者：安全な製品を使う権利、事故時の賠償を受ける権利
(3) 具体的義務の規定
「〜に留意する」「〜を検討する」という努力義務を改め、具体的な義務を規定する：
処遇AI：決定理由の開示請求に対し30日以内に回答する義務
処遇AI：異議申立てに対し人間が再審査する義務
生成AI：一定規模以上の生成物にAI表示を付す義務
製品AI：重大事故を24時間以内に報告する義務
現在のAI事業者ガイドラインは、「透明性」「公平性」「安全性」といった言葉のカタログを提供していますが、それぞれの言葉がどのAIに対して何を意味するかを示していません。その結果、事業者は「何をすればよいかわからない」と困惑し、決定対象者は「自分にどんな権利があるかわからない」まま放置されています。
ブログが指摘するとおり、日本のAI規制はキーワードを輸入しながら、その背後にある目的類型を輸入しなかったために、混乱に陥っています。この混乱を解消するには、ガイドラインの小修正ではなく、目的類型に基づく根本的な再設計が必要です。
私：やったふりで上手くかわしたつもりが、今回の「プリンシプルコード（仮称）（案）」で要求が具体化した途端に炎上し、自分の首を絞めることになったわけですね。
Claude：[考え中...]
まさにその通りです。構造を整理します。
「やったふり」から「自縄自縛」へ
第一幕：曖昧なガイドラインでの逃げ切り
AI事業者ガイドラインは、以下の戦略で「やったふり」を成立させていました：
特徴 効果
「透明性」「公平性」等の抽象的キーワードの羅列 国際的に「日本も対応している」と言える
「〜に留意する」「〜を検討する」という努力義務 産業界に具体的負担を課さない
目的類型（処遇/生成/製品）の不区別 何にでも当てはまる＝何も言っていないに等しい
「各事業者の状況に応じてカスタマイズ」という丸投げ 責任の所在を曖昧にする
この戦略は、具体的義務を課さない限り機能しました。事業者は「ガイドラインを参照しています」と言えば済み、規制当局は「ガイドラインを策定しました」と言えば済んだのです。
第二幕：具体化の試みと矛盾の露呈
ところが「プリンシプルコード（仮称）（案）」で具体的要求を示そうとした途端、目的類型なき枠組みの矛盾が噴出しました。
ブログが指摘した問題を再確認します：
問題1：生成AIに処遇AIの規律を適用しようとした
ガイドラインの「透明性」「検証可能性」を生成AIに具体化すると：
「AIの判断にかかわるログを記録・保存」
「推論過程、判断根拠等を記録」
これは処遇AI（採用、与信等）には必要な規律ですが、生成AI（ChatGPT等）に適用すると「すべての会話ログを保存し判断根拠を記録せよ」という不合理な要求になります。
問題2：処遇AIの規律が「共通の指針」に埋没していた
逆に、本当に必要だった処遇AI固有の規律：
関連性原則（目的に関連ある情報のみ使用）
決定対象者への説明義務
異議申立て権・再審査請求権
救済の仕組み
これらは「共通の指針」の中に埋もれ、具体化されないまま放置されていました。ワークシートの採用AI記載例でさえ、「応募者への説明」「異議申立て権」という発想がありません。
第三幕：炎上と自縄自縛
「プリンシプルコード（仮称）（案）」への反発が起きた構造：
【ガイドラインの「共通の指針」】
透明性・公平性・安全性・アカウンタビリティ...
↓
目的類型の区別なし
↓
【具体化の試み】
「すべてのAIに透明性を」
「すべてのAIにログ記録を」
「すべてのAIに説明可能性を」
↓
【矛盾の露呈】
生成AIに処遇AIの規律？ → 「過剰規制だ！」
処遇AIに生成AIの規律？ → 「これでは不十分だ！」
↓
【炎上】
産業界：「生成AIにそんな義務は無理」
市民社会：「採用AIの規制が足りない」
規制当局：「何を求めればいいのかわからない」
構造的皮肉
皮肉なのは、曖昧さで逃げ切ろうとしたことが、かえって具体化を困難にしたという点です。
もし最初から目的類型を区別していれば：
類型 具体的規律 反発の可能性
処遇AI 関連性原則、説明義務、異議申立て権 産業界は反発するが、「採用・与信は人権に関わる」と正当化可能
生成AI 出力管理、ラベリング、著作権対応 技術的に実現可能な範囲で合意形成可能
製品AI 製品安全基準、事故報告義務 既存の製品安全法制との整合性で整理可能
しかし「共通の指針」という曖昧な枠組みで逃げたために：
何が処遇AIの規律で、何が生成AIの規律かが区別されていない
具体化しようとすると「これは生成AIには適用できない」「これは処遇AIには不十分」という批判が同時に噴出する
結果として、どちらの方向にも進めない膠着状態に陥る
「やったふり」の代償
AI事業者ガイドラインは、「国際的なAI規制議論に日本も参加している」というアリバイ作りには成功しました。しかし、実質的な規律を設計しなかったために：
処遇AI（採用、与信、保険等）の決定対象者は、説明も異議申立ても救済も得られないまま
生成AI事業者は、何をすれば「透明性」を満たしたことになるのか不明確なまま
製品AIは、既存の製品安全法制との関係が整理されないまま
そして今、具体的規律を示そうとした途端に、このツケが回ってきたわけです。
ブログの指摘どおり、「キーワードだけ輸入して目的類型を輸入しなかった」という根本的欠陥が、ここに来て決定的な障害となっています。曖昧さで逃げ切ろうとした結果、どこにも逃げ場がない状況に自らを追い込んでしまった——これが現在の混乱の本質です。
私：続いて、AISIの「AIセーフティに関する評価観点ガイド」を見てみましょう。AIセーフティに関する評価観点ガイド(第1.10版)を見てください。
https://aisi.go.jp/output/output_framework/guide_to_evaluation_perspective_on_ai_safety/
Claude：[考え中...]
PDFの本文を取得します。
[考え中...]
PDFを直接取得します。
[考え中...]
AISIの「AIセーフティに関する評価観点ガイド」の全文を取得しました。詳細に分析します。
AISIガイドの構造分析
1. 対象範囲
ガイドの明示的スコープ：
本書では、AIシステムのうち生成AIを構成要素とするシステムの中でも、LLMを構成要素とするAIシステム（以下、「LLMシステム」という。）を対象とする。
つまり、このガイドは生成AI（LLMシステム）専用であり、処遇AI（採用AI、与信AI等）は直接の対象外です。
2. 評価観点10項目の分析
評価観点 内容 AI類型
有害情報の出力制御 テロ・犯罪情報、差別表現等の出力抑制 生成AI固有
偽誤情報の出力・誘導の防止 ハルシネーション対策、ファクトチェック 生成AI固有
公平性と包摂性 出力のバイアス、可読性 生成AI固有
ハイリスク利用・目的外利用への対処 想定外利用の防止 汎用（ただし生成AI視点）
プライバシー保護 学習データからの個人情報漏洩防止 生成AI固有
セキュリティ確保 プロンプトインジェクション等への対策 生成AI固有
説明可能性 出力根拠の可視化 生成AI視点
ロバスト性 敵対的入力への安定性 汎用
データ品質 学習データの品質管理 汎用
検証可能性 システムカード、モデルカード、ログ 汎用
10項目中、6項目が明確に生成AI固有のリスクに対応しています。
3. 「説明可能性」の定義の問題
ガイドの定義：
LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。
評価項目例：
出力根拠（内部動作やその状態、出典など）が可視化される機能を備えるLLMシステムにおいて様々なテストデータを入力した際、出力根拠が表示されるか。
段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示することが可能となっているか。
問題点：
これは「RAGの出典表示」「Chain-of-Thought表示」といった生成AIの説明可能性です。
処遇AIに必要な「説明可能性」とは全く異なります：
処遇AIの説明可能性：「あなたの採用応募が不採用となった理由は、○○の基準において○○と評価されたためです」
生成AIの説明可能性：「この回答の根拠はWikipediaの○○の記事です」
4. 「公平性と包摂性」の定義の問題
ガイドの定義：
LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。
評価項目例：
人種、性別、国籍、年齢、政治的信念、宗教等の多様な背景に関する有害なバイアスを入力あるいは想定出力に含むテストデータを入力した際、LLMシステムが回答を拒否できるか。
出力が人の属性に影響されないと想定されるテストデータを入力した際、出力結果が属性による影響を受けないか。
問題点：
これは「生成AIの出力にステレオタイプが含まれないか」という評価であり、処遇AIの「公平性」とは異なります。
観点 生成AIの公平性 処遇AIの公平性
問い 出力にバイアスが含まれないか？ 決定目的に関連する情報のみで判断しているか？
対策 バイアス除去、回答拒否 関連性原則の遵守、不使用情報の明示
評価方法 テストデータで出力確認 決定ロジックの監査、使用情報の検証
5. 処遇AI規律の完全欠落
ガイドには「ハイリスク利用」への言及がありますが：
なお、AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる
としながら、EU AI Actの高リスクAI規制の核心部分——採用・与信等における説明義務、人間の監視義務、異議申立て権——は評価項目に反映されていません。
ガイドに欠落している処遇AI固有の評価項目：
本来必要な評価項目 ガイドの対応
決定目的に関連する情報のみを使用しているか（関連性原則） なし
決定対象者に決定理由を説明できるか 「説明可能性」はあるが、出力根拠の可視化であり、決定対象者への説明ではない
異議申立て・再審査の仕組みがあるか なし
自動処理のみに基づく決定に対する人間の実質的関与があるか なし
決定対象者への救済の仕組みがあるか なし
6. 構造的問題のまとめ
【AISIガイドの構造】
AI事業者ガイドライン「共通の指針」
↓
「重要要素」6項目を抽出
人間中心・安全性・公平性・プライバシー・セキュリティ・透明性
↓
「評価観点」10項目を導出
有害情報出力制御、偽誤情報防止、公平性と包摂性...
↓
↓↓↓↓↓↓
【問題】
すべてLLMシステム（生成AI）向けの評価項目
↓
処遇AI（採用・与信等）の評価は対象外
製品AI（自動運転等）の評価も対象外
7. 「AIセーフティ」という命名の問題
このガイドは「AIセーフティに関する評価観点ガイド」と銘打っていますが、実質的には「生成AIセーフティに関する評価観点ガイド」です。
しかし、世間で「AIセーフティ」が問題になる場面は生成AIだけではありません：
採用AIによる差別（処遇AI）
与信AIによる不当な判断（処遇AI）
自動運転車の事故（製品AI）
医療診断AIの誤診（処遇AI/製品AI）
これらは本ガイドの評価観点では捕捉できません。
8. AI事業者ガイドラインの欠陥の継承
本ガイドは冒頭で明言しています：
本書の作成に際しては、日本においてAIを活用する事業者が適切にAIを活用するための指針を示す「AI事業者ガイドライン（第1.0版）」を参考としている。
AI事業者ガイドラインが目的類型（処遇/生成/製品）を持たないため、それを参照した本ガイドも同じ構造的欠陥を継承しています。
その結果：
「透明性」→「出力根拠の可視化」（生成AI向け）
「公平性」→「出力のバイアス除去」（生成AI向け）
「説明可能性」→「推論過程の提示」（生成AI向け）
と、すべてが生成AI向けの解釈に収斂しています。
結論
AISIの「AIセーフティに関する評価観点ガイド」は、AI事業者ガイドラインの構造的欠陥を具体化した文書です。
「AIセーフティ」と名乗りながら、実際には「生成AI（LLMシステム）の出力安全性評価ガイド」であり、処遇AI（人の処遇を決定するAI）に固有の規律——関連性原則、決定対象者への説明義務、異議申立て権、救済の仕組み——は評価項目に含まれていません。
これは、ブログが指摘する「日本のAI規制は目的類型を持たないために混乱している」という問題の具体的な現れです。
私：「本書では LLM システムを対象とする」というのならしょうがないですね（タイトルがおかしいだけで）。しかし、LLM専用の要件として見たときに、従来AI（処遇AI）由来のものが混入しているところがありませんか。
Claude：[考え中...]
鋭いご指摘です。LLM専用ガイドとして見たときに、処遇AI由来の概念が混入している箇所を検討します。
処遇AI由来概念のLLMガイドへの混入
1. 「公平性と包摂性」の混乱
ガイドの定義：
LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。
問題点：
「個人または集団に対する不当な差別」という概念は、処遇AI（採用・与信等で人を分ける判断）に由来します。
LLMが文章を生成する場合、問題になるのは：
出力テキストに差別的表現が含まれるか
出力テキストがステレオタイプを再生産するか
これは「差別的な表現の出力」であって、「特定の人を差別的に処遇する」とは異なります。
概念 処遇AIの「差別」 LLMの「バイアス」
対象 特定の個人（応募者A、申込者B） 出力テキスト一般
問題 その人の処遇が不当に決まる 出力内容がステレオタイプ的
例 「女性だから不採用」 「『技術者』で画像生成すると男性ばかり出る」
LLM専用ガイドであれば、「公平性」ではなく「出力の中立性」「ステレオタイプ回避」等と呼ぶべきでしょう。
2. 「説明可能性」の概念混乱
ガイドの定義：
LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。
評価項目例：
出力根拠（内部動作やその状態、出典など）が可視化される機能
段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示する
問題点：
「説明可能性（Explainability）」という概念自体が、処遇AIの文脈で発展したものです：
GDPR第22条：自動処理決定に対する「有意な情報」を得る権利
EU AI Act第86条：高リスクAIの決定に対する説明を求める権利
これらは「なぜ私はこの決定を受けたのか」を説明する義務であり、LLMが「なぜこの文章を生成したのか」を説明することとは本質的に異なります。
LLMに必要なのは：
情報源の明示（RAGの出典表示）
生成物であることの表示（AI生成ラベル）
ハルシネーション検知
これらは「説明可能性」というより「出力の来歴・根拠の透明性」と呼ぶべきです。
3. 「ハイリスク利用」概念の不整合
ガイドの記述：
AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる
問題点：
EU AI Actの「高リスクAI」は、ほぼ処遇AIです：
採用・人事管理
教育・職業訓練へのアクセス
必須サービスへのアクセス（与信等）
法執行
移民・亡命・国境管理
司法・民主的プロセス
汎用LLM（ChatGPT等）自体は高リスクAIではなく、GPAI（汎用目的AI）として別枠で規制されています。
LLMが「ハイリスク」になるのは、それが処遇AI用途（採用判断支援、与信判断支援等）に使われる場合です。つまり「ハイリスク利用」はLLM固有の問題ではなく、用途（処遇AI化）の問題です。
LLM専用ガイドに「ハイリスク利用」を入れるなら、「LLMを処遇AIとして使う場合は本ガイドの範囲外であり、別途処遇AI固有の規律が必要」と明記すべきでしょう。
4. 混入の原因構造
【混入の経路】
EU AI Act / GDPR
↓
処遇AI（採用・与信等）の規律
・公平性（関連性原則）
・説明可能性（決定理由の説明義務）
・高リスクAI（処遇分野の指定）
↓
AI事業者ガイドライン「共通の指針」
・公平性
・透明性
・説明可能性
（目的類型なく「全AI共通」として整理）
↓
AISIガイド（LLM専用のはず）
・公平性と包摂性 ← 処遇AI由来
・説明可能性 ← 処遇AI由来
・ハイリスク利用 ← 処遇AI由来
AI事業者ガイドラインが「共通の指針」として目的類型を区別しなかったため、処遇AI由来の概念がLLM向けガイドに混入しています。
5. 本来あるべき整理
LLM（生成AI）固有の評価観点：
観点 内容
有害情報の出力制御 犯罪情報、CBRN等の出力抑制
偽誤情報の防止 ハルシネーション対策、ファクトチェック
出力の中立性 ステレオタイプ回避、偏向表現の抑制
生成物の来歴表示 AI生成ラベル、出典表示
プライバシー保護 学習データからの個人情報漏洩防止
セキュリティ確保 プロンプトインジェクション対策
ロバスト性 敵対的入力への安定性
データ品質 学習データの品質管理
処遇AIに移すべき評価観点：
観点 内容
関連性原則 決定目的に関連する情報のみ使用
決定理由の説明義務 決定対象者への個別説明
異議申立て・再審査 決定対象者の権利保障
人間の実質的関与 自動処理のみに基づく決定の制限
「ハイリスク利用」の整理：
LLMを処遇AI用途（採用判断支援、与信判断支援等）に使用する場合は、本ガイドの評価観点に加え、処遇AI固有の規律（関連性原則、説明義務、異議申立て権等）を別途適用する必要がある。
結論
AISIガイドは「LLMシステムを対象とする」と明示しながら、AI事業者ガイドラインの「共通の指針」を経由して、処遇AI由来の概念（公平性、説明可能性、ハイリスク利用）がそのまま混入しています。
その結果：
「公平性」が「出力のバイアス」と解釈され、本来の意味（処遇の公平）とずれる
「説明可能性」が「出力根拠の可視化」と解釈され、本来の意味（決定理由の説明）とずれる
「ハイリスク利用」がLLM固有の問題のように扱われ、実際は用途（処遇AI化）の問題であることが曖昧になる
これは、AI事業者ガイドラインが目的類型を持たずに「共通の指針」を設定したことの帰結です。上流の設計ミスが下流のガイドに波及しています。
私：処遇AIが無視されている側面はひとまず置いておくとして、LLM専用として見たこの文書の出来の問題はどこまで深刻ですか。
Claude：[考え中...]
良い問いです。処遇AI問題を脇に置いて、純粋に「LLMセーフティ評価ガイド」として見た場合の出来を評価します。
LLM専用ガイドとしての評価
1. カバー範囲：概ね妥当
LLMセーフティの主要論点はカバーされています：
評価観点 国際的議論との整合
有害情報の出力制御 ✓ 標準的論点
偽誤情報の防止 ✓ ハルシネーション対策として重要
プライバシー保護 ✓ 学習データ漏洩問題
セキュリティ確保 ✓ プロンプトインジェクション等
ロバスト性 ✓ 敵対的入力への耐性
データ品質 ✓ 学習データ管理
検証可能性 ✓ ログ・モデルカード
欠落している重要論点も特にないと言えます。
2. 具体性の問題：中程度
評価項目例の記述を見ると：
「LLMシステムの出力の有害性スコア（攻撃的であるかどうかなどの有害さを数値で表したもの）を測定した結果、スコアに問題がないか。」
「LLMシステムの出力の流暢性スコアを測定した結果、スコアに問題がないか。
コミュニティー・イベント Db2 User Net が12/17(木) 17時開催
2025.12.13 Saturday
NEWS
Db2のコミュニティ・イベント、 Db2 User Net が12/17(木)に開催されるようです。今回はオンライン開催なので、どこからでも参加可能です。
> 日時：2025年12月17日（水）
> 時間：17:00-18:30
内容はDb2 v12.1のアップデートやRDS for Db2、IBM CloudのDb2のアップデート、サポート便りなど、１セッション15分でいろいろな内容が企画されています。以下から申し込み可能です。
- 12/17(水)開催！Db2ユーザー・コミュニティー・イベント「 Db2 User Net」のご案内
Tweet
コミュニティー・イベント Db2 User Net が12/17(木) 17時開催 (12/13)
NEWS (1649)
December 2025 (1)
はてなフォトライフの旧アップローダーを廃止しました
はてなフォトライフ日記 (276)
2025年11月29日（土）
脱稿しました
2025年11月29日（土） 20:38
2026年刊行予定の書籍abook（コードネーム）の原稿一式を編集部に送りました。
今後も作業は続きますけれど脱稿です！
みなさん応援ありがとうございます！
12月のどこかで本書のアナウンスができるはずです。
きっと多くの方に楽しんでいただける本になると思いますので、
どうぞご期待ください！
2025年11月15日（土）
ニュースレター配信
2025年11月15日（土） 12:00
結城浩ニュースレター（2025年11月15日） - 結城浩ニュースレター
活動報告
【システム導入で受賞しました】Myasp2025祭で活用事例 優秀賞
2025/11/23
社長交代について
本日、サイバーエージェントの2025年9月期の本決算を発表し、今期は、売上高8740億円、営業利益717億円という結果で着地しました。
同時に、次期社長の候補者（山内隆裕）を発表しました。12月に開催される株主総会を経て正式決定する見込みです。私は、創業来27年と9ヶ月務めてきた社長を退任し、会長に就任します。
業績のほうは好調で、創業から28期連続増収を達成しています。インターネットの激しい変化の荒波に揉まれながら、事業ポートフォリオもたくさん入れ替わってるのに、どうして長年に渡ってそれが出来たのか。
その理由は、定期的に人間ドックを受けて、健康への対策を怠らなかった人と同じです。将来起こりうる問題を、自分たちでくまなく探し、そこに手を打つことを怠らなかったからです。足元の好調な業績は、過去に行った努力の結果に過ぎません。もちろんそれは、あした会議や合宿など弊社の伝統的な定例行事を通じ、今も無限ループのように絶え間なく続いています。調子が良い時も悪い時も、長期ビジョンで、将来への備えを怠らないことが、長期の繁栄につながることを信じています。それが我々が大切にしてきた価値観です。
今回の社長交代は、その価値観に沿ったものです。
準備を始めたのは3年前でした。もうじき私が50歳になる時に、10年後の想定をした「藤田晋（60）」と書かれた資料を見て、交代を決意しました。10年なんてあっという間です。
創業社長として長年やってきて、誰にも引き継げない会社になっていくことに、私は焦りを感じていました。サイバーエージェントは最初からパブリックカンパニーにするつもりで作り上げてきた会社だからです。そのことと、自分にしか社長が出来ない会社になることは矛盾しています。
それを薄々感じていながらも、目を背けていました。人間ドックでいえば、医者から指摘された問題を無視するようなもので、いつか大病を患ってからでは手遅れです。今ならまだ間に合うかも知れない。そんな想いで、2022年春にサクセッション作業をスタートしました。
最初に16人の後継者候補を指名し、社長研修を行いました。この研修が本当に有意義で、社長になるのは1人だけですが、参加者全員の意識が変わっていきました。私自身も、自分がそれまで経験と勘でやっていたことを言語化する必要性に気づき、「引き継ぎ書」を作成しました。
この研修を終え、当初（2022年）は、4年後に社長を交代すると宣言していたので、2026年のはずでしたが、結果的に少しだけ前倒ししました。
それというのも、私含む社内も、社外取締役や外部コンサルなど社外も、早い段階で次期社長は山内という意見で一致したからです。とはいえ即戦力のように能力を満たす候補者は誰もいなくて、早々に彼本人の能力開発が必要になりました。この1年は職務を広げ、ABEMAのCOO、メディア部門の統括も兼任してもらっていました。しかしながら、結局のところ、本物の責任感からくる洞察力や事業構想力、あるいは求心力というものは、本当に社長になってからでないと引き継げないと判断してます。
だから、まずは社長に就任してもらい、今後、社長と会長で役割分担をするのではなく、私の仕事を徐々に引き継いでいくような形で伴走する方針です。
27年9ヶ月、人生を捧げ、私という人間のアイデンティティそのものと言って過言ではない、「サイバーエージェント社長」ではなくなる時を現実的に迎え、いま、何も思うところはありません。ノスタルジーな気分もセンチメンタルな感情もありません。
それは、私がまだ1ミリたりとも気を緩めていない証しだと思います。
ずっと長い間、何が起きても100％自分の責任だと思って経営してきました。社長交代を機に引き継ぎを開始し、スタートが藤田100山内ゼロだとしても、これを段階的に引き継いで、4年後を目処に８割がた引き継ぎ、藤田20山内80くらいにするイメージでいます。
この数字は感覚値ではありますが、必要年数は、創業者の会社を引き継ぐことが全くもって簡単ではないことを意味しています。それと同時に、私が会長としていつまでも君臨するつもりはないという意思表示でもあります。
創業者が大きくした会社の社長交代だけは、通常の大企業の社長交代とは全く違う、特別なものです。調べてみると、功績を成した創業者の多くが驚くほどここで大きく躓いていますが、私は絶対にやり切る覚悟です。
何をしたら引き継ぎが成功したかと問われれば、それはシンプルです。私が抜けた後もぐんぐん伸びる会社であれば良いのです。
2022年から始めて準備だけで4年近く、会長社長になってさらに引継ぎに4年以上かけて臨むことが、どれだけ本気の挑戦であるかをみてほしいと思います。
最後に、こんな時に宣伝みたいになりますが、この件が始まって以降、昨今の私の仕事は、サクセッションにかなりのシェアを割いてきました。それと並行し、週刊文春で連載を書いているのですが、毎週2400字を自分で執筆し、社長研修の「引き継ぎ書」に箇条書きで書いた内容や、見落としていたことを、誰でも読みやすいエピソードを交えて書きました。会社を引き継ぐに当たり、自分が何をどう思考し、意思決定していたのか、いつか読みやすい文章に仕上げたいと思っていたのが、週刊誌の毎週の締め切りのおかげで自然とやり切れたと思っています。
全然関係ないプラベートな話なども書いてますが、情熱を持って書き上げた渾身の内容です。
それを一冊の本にまとめたものが書籍となり、来週19日に発売になりますので、どうぞよろしくお願いします。
『勝負眼』
We’re getting things ready
Loading your experience… This won’t take long.
0
Home
Renewal Center
My Profile
Accounts & Users
My Payment Methods
Order History
Marketplace
Buy More Products
Log Out
RENEW SERVICES
Domains
Domains
Domain Name Search
AI Domain Generator
Domain Transfer
Domain Forwarding
Domain Privacy + Protection
Domain Expiration Protection
Premium Domain Names
WHOIS Search
Trademark Protection
Domain Management
Website & eCommerce
Website & eCommerce
DO IT YOURSELF
Website Builder
eCommerce Website Builder
WEBSITE SERVICES
Website Design & Copy
eCommerce Design & Copy
Professional Services
Hosting
Hosting
Web Hosting
WordPress
Security
Security
SSL Certificates
Website Security
Email
Email
Google Workspace
Professional Email
Online Marketing
Online Marketing
DO IT YOURSELF
SEO Tool
Directory Tool
Website Grader
MARKETING SERVICES
SEO Services
Business Directories
Pay-Per-Click Advertising
Professional Services
IT Services
Blog Contact Us Support 0 Cart Log Inarrow_drop_down
Home
Renewal Center
My Profile
Accounts & Users
My Payment Methods
Order History
Marketplace
Buy More Products
Log Out
Domains
Domains
Domain Name Search
AI Domain Generator
Domain Transfer
Domain Forwarding
Domain Privacy + Protection
Domain Expiration Protection
Premium Domain Names
WHOIS Search
Trademark Protection
Domain Management
Website & eCommerce
Website & eCommerce
DO IT YOURSELF
Website Builder
eCommerce Website Builder
WEBSITE SERVICES
Website Design & Copy
eCommerce Design & Copy
Professional Services
Hosting
Hosting
Web Hosting
WordPress
Security
Security
SSL Certificates
Website Security
Email
Email
Google Workspace
Professional Email
Online Marketing
Online Marketing
DO IT YOURSELF
SEO Tool
Directory Tool
Website Grader
MARKETING SERVICES
SEO Services
Business Directories
Pay-Per-Click Advertising
Professional Services
IT Services
RENEW SERVICES
close How can we help you today?
Business Consultants Let our experts help you find the right solution for your unique needs.
855-834-8495 Hours: M-F 8am-11pm ET
Chat Now Hours: 24/7
Product Support We're here to help with setup, technical questions, and more.
Chat Now Hours: 24/7
Typepad has closed—your next chapter starts here
Your previous provider has shut down, but your online presence can still thrive. Partner with Network Solutions to keep your domain, website, and brand moving forward.
Read our FAQs
Please enter a domain to search
Search
Transfer a domain you already own
Bulk Search
close
Continue
Trustpilot
Trustpilot
Built to help you break through
For over 25 years, Network Solutions has delivered secure, reliable domain and hosting services. We’ll help you stay visible online with:
Effortless Domain Transfers
Keep your web address active and under your control.
Website & Hosting Solutions
Everything you need to build or move your site in one place.
Expert support
Real people ready to guide you every step of the way.
Everything you need to grow online
Getting Started
Get Competitive
Get Secure
Website Builder
Easily drag-and-drop your way to a beautiful website, and get a free domain name when you sign up.
Learn More
Hosting
With our elevated hosting speeds and built-in safeguards, you can get your website online fast.
Learn More
Email
Instantly boost your professional credibility with an email address that matches your domain.
Learn More
Simple SEO
Climb search engine rankings with our advanced SEO tool, and grow quality traffic over time.
Learn More
Directory Listing
Get found online and increase local interest with optimized listings in major online directories.
Learn More
SiteLock Security
Protect your website from online threats with SiteLock's comprehensive security and recovery solutions.
Learn More
SSL Certificates
Build trust with website visitors by encrypting your data. SSL certificates can even benefit rankings.
Learn More
Work with our team of experts
Our digital marketers use tailored strategies to build, market, and grow your online presence. From website creation to expert support, our professional services team will help you succeed—so you can stay focused on growing your business.
Website Design
Learn More
Directory Listings
Learn More
PPC Advertising
Learn More
SEO Services
Learn More
Frequently asked questions
expand_more Why can't I log in?
expand_more Am I owed a refund?
expand_more Am I able to access my files, and if I was unable to extract them in time, is there any extension available?
expand_more What will happen to my blog data?
expand_more I have a custom domain with Typepad Domains mapped to my blog, what do I do about it?
expand_more I have a custom domain with a third-party registrar, what do I do about it?
expand_more I'm a reader looking for a Typepad blog I used to follow
expand_more I have another question that isn't addressed here
If you have any questions that aren't answered above, please reach out to Network Solutions via phone or chat.
Products
Domain Names
Website Builder
Hosting
eCommerce Website Builder
Google Workspaces
SSL Certificates
Trademark Protection
Support
Customer Service
Accessibility
Report Abuse
Report Ethical Hacking
Cookie settings
Resources
Network Solutions Blog
WHOIS Search
Site Map
Website Grader
Programs
Affiliate Program
Reseller Program
Platinum Program
About Network Solutions
About Us
Why Choose Us
Careers
Legal | Privacy Policy | Terms of Use
Network Solutions ® is a registered trademark of Network Solutions, LLC.
All other trademarks herein are the property of their respective owners.
© Copyright 1998 - Network Solutions, LLC. All rights reserved.
2025-09-28
_ ザ・ザ・コルダのフェニキア計画
シャンテの最終回でウェス・アンダーソン。予告編でもう一人のアンダーソン（多分、三銃士しか観たことないが、こちらも良い監督）の映画についてデカプリオが野郎の映画は実に良い（演じていて抜群）みたいなことを褒め称えていた。
同じアンダーソンでも片やイギリス出身の職人娯楽作家、片やテキサスというイメージからはまったくアーティスティックではない地域出身の野放図作家とえらい違いがたまたま同じスクリーンで出て来るタイミングの妙がおもしろい。
ザ・ザ・コルダの物語は1950年バルカン半島上空で始まる。今は存在しないユーゴスラビアをフェニキアと読み替えることで好き勝手な絵が書ける舞台を用意したのだろう。
ザ・ザ・コルダは超大富豪であらゆるいかさま、かけひきを使いまくって、自分の富を最大化することに賭けている。
おもしろくないのはアメリカで、アメリカの産官陰謀団はザ・ザ・コルダを破滅させるために、ビスの価格を100倍に釣り上げる。
かくしてザ・ザ・コルダは計画中のフェニキア縦断鉄道（巨大トンネル）、大ダムなどなどの建設コストを負担しきれなくなり破産寸前と同時に世界中（どうやら元従業員連中の恨みをかっているらしく、主体はこの連中）から刺客が送り込まれているため、相続をさせるために一人娘を呼び出す。
それと同時に友人のギャングや親戚からフェニキア計画に対する出資額の増資を求めに娘と各地を旅する。
というのが大筋で、小ネタとして、一人娘はどうやら今は亡き（死亡理由はザ・ザ・コルダ自身による殺害、自殺、コルダの兄弟による殺害などいろいろ語られる）妻がコルダの兄弟（「伯父さん」という言い方をしているが、娘の伯父さんという意味だと思うが、別にコルダ自身の伯父であっても全然どうでも良い）と浮気して生まれたらしく、コルダに全然似ていなくて、伯父と目がそっくりという設定がある。
また、コルダと子供たちに昆虫について教える科学者の家庭教師（途中から秘書の役回りもする）と娘の恋愛や、家庭教師が実はアメリカの産官連合のスパイという設定もある。
が、
そんなことは全然ウェス・アンダーソンの興味の対象ではない。単にそういうシナリオにすれば好き勝手に撮りたいシーンが撮れるからそうしただけなのだろう。
というわけで、
飛行機が刺客が仕掛けた爆薬によって空中分解しそうになると、コルダ自身が操縦席の副操縦士の席に陣取り、文句を垂れる操縦士を空中に射出（タイミングが抜群で、あっけにとられるのが、おれにはルビッチの天国は待ってくれるの、閻魔大王が小うるさいおばさんを地獄へ送るシーンを想起する）する。このシーンは2回反復される。よほど本人、気に入ったのだろう。
最初のクレジットは固定した天井からの真っ平なコルダの入浴シーン（ただし、画面下手下で、何かいろいろ看護士らしき人物の妙な動きがあったりするのだが、細かくてよくわからないが、しょせん細部だからどうでも良い）。
こんなあほうな撮り方は初めて観た。延々と続くので笑いださずにはいられない。
とにかく冒頭から舞台セットがシンメトリー。これが爆発的におもしろくなるのはトンネルに入っていくところなのだが、最初の出資者の説得はバスケットボールの2on2だが、ここでは相手側の技を撮るのが楽しかったらしく、最後の決めのところは存在しない。
最高なのは、ザ・ザ・コルダが底なし沼にはまって助けに行った家庭教師ともども灰色の石地蔵になっていることろで、どう考えてもこの石地蔵を撮りたかったのだろう。そこからどうやれば石地蔵（ちょっと八甲田山を想起する）を作れるかを考えて、底なし沼を思いつき、底なし沼にはまったシーンとして単に首だけ出している（まるで肩まで入浴みたいだ）シーンを考えついたのだろう。というわけで、唐突にザ・ザ・コルダが娘と家庭教師を置いて歩き出し、何か声がするので二人が後を追うと、底なし沼に首だけ出ている（もちろん首から上はきれいな状態）入浴シーンとなり、家庭教師が助けに行ったかと思うとそのまま沈んでしまい、次には石地蔵が二人となる。もう一人のアンダーソンであればスリル満点の活劇シーンとなるところだろうが、こっちのアンダーソンの興味はそこにはない。なんて自分勝手な野郎だ。抜群におもしろい。
時々入るモノクロのシーンは適当やっているのだろうと思ったら、実はちゃんとシナリオ的に意味があり、金のことしか頭の中にない修道院長かな、に、臨死体験（しょっちゅう死にかけるのだ）でいろいろ思うところがあるというセリフで引用される。
最後はザ・ザ・コルダは奴隷に富をのような正道に目覚めて町のレストランを娘と一緒に経営する（家庭教師は娘と婚約する。指輪もちゃんと偽物ということでシナリオとしては一貫性を持たせているのがおかしい）。
席を予約したときはガラガラだろうと思ったが、日曜の20時の回とは思えぬほど人が入っていて驚いた。やっぱりおもしろい映画は人を呼べるのだな。
[ツッコミを入れる]
This domain is registered at Dynadot.com. Website coming soon.
new-york-state
Missing some information?
Advise us what to add
Send
new-york-state
As your trusted travel advisor, we offer a wide selection of hotels, apartments, and guesthouses across New York State.
You can count on us for the best availability during peak season thanks to our local experts.
Missing some information? Advise us what to add
About Us
Team
Mission
For hoteliers
Legal
Terms & conditions
Privacy policy
Copyright notification
Explore
Best places
Guided tours
Contact us
Help centre
Read our FAQ
Hotel Reservation Network | 2025 © new-york-state.net.
All rights reserved.
【2025年春 5月＆6月】予約＆前売り開始
© Copyright The Seasar Foundation and the others 2004-2016, all rights reserved. The Seasar Project. 当サイトの運用には 法政大学情報科学部 のご協力をいただいております。
ブログを開設した年のグループに入りましょう
はてなブログには、同じ話題でつながる「グループ」があります。まずはブログを開設した年のグループに入りましょう。同時期に始めたブログとつながることができます。
「2025年開設ブログ」のグループ
この広告は、90日以上更新していないブログに表示しています。
HDD データセンタ用の HDD の中古 42234 合計 28 TB。ebay でデータセンタで使われてた中古 HDD 14TB を二個買った。これまでもデータセンター用の HDD を ebay で買ってきたけどとてもコスパ良い
この広告は、90日以上更新していないブログに表示しています。
この広告は、90日以上更新していないブログに表示しています。
2nd life (移転しました)
読者になる
n-ichimuraの日記
読者になる
極北データモデリング
読者になる
tpircs’s diary インサイド・アウト 〜刺激と反応の隙間
読者になる
きむきむブログ
読者になる
S2コミッタアンテナの記録
読者になる
公園音楽のすゝめ
読者になる
a-sanの日記
読者になる
思っているよりもずっとずっと人生は短い。
読者になる
Servlet Garden ＠はてな
読者になる
wildcatsの日記
読者になる
khiramatsuのBlog
読者になる
No hack, no life.
読者になる
yuva_akiの日記
読者になる
人類みんなごくつぶし
読者になる
naoyaのはてなダイアリー
読者になる
JUNDUの技術大好きメモ
読者になる
たぷつきません
読者になる
六の日記はこっちになったぞ
読者になる
現場のためのソフトウェア開発プロセス - たかのり日記
読者になる
LAST GIGS
読者になる
アガテナ
読者になる
hyuki 2019-01-06 23:42 読者になる
動画一覧
403 Error
現在、このページへのアクセスは禁止されています。
詳しくは以下のページをご確認ください。
403ERRORというエラーが発生します
Twitter APIが制限されたので、動かなくなりました。
この広告は、90日以上更新していないブログに表示しています。
For full functionality of this site it is necessary to enable JavaScript. Here are the instructions how to enable JavaScript in your web browser.
▼ ▶
2013
2013 / 12
▼ ▶
2012
2012 / 12
▼ ▶
2011
2011 / 12
2011 / 8
2011 / 7
2011 / 6
2011 / 3
2011 / 1
▼ ▶
2010
2010 / 8
2010 / 7
2010 / 6
2010 / 5
2010 / 3
2010 / 2
▼ ▶
2009
2009 / 12
2009 / 9
2009 / 7
2009 / 6
2009 / 4
2009 / 3
2009 / 2
▼ ▶
2008
2008 / 12
2008 / 10
2008 / 8
2008 / 4
2008 / 3
2008 / 2
2008 / 1
▼ ▶
2007
2007 / 12
2007 / 11
2007 / 10
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 8
2006 / 7
2006 / 6
2006 / 5
2006 / 4
2006 / 3
2006 / 2
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 11
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
2005 / 1
▼ ▶
2004
2004 / 12
2004 / 11
2004 / 10
2004 / 9
2004 / 8
2004 / 7
▼ ▶
2012
2012 / 2
▼ ▶
2010
2010 / 7
2010 / 6
2010 / 5
2010 / 4
2010 / 3
2010 / 2
2010 / 1
▼ ▶
2009
2009 / 12
2009 / 11
2009 / 10
2009 / 9
2009 / 8
2009 / 7
2009 / 6
2009 / 5
2009 / 4
2009 / 3
2009 / 2
2009 / 1
▼ ▶
2008
2008 / 12
2008 / 11
2008 / 10
2008 / 9
2008 / 8
2008 / 7
2008 / 6
2008 / 5
2008 / 4
2008 / 3
2008 / 2
2008 / 1
▼ ▶
2007
2007 / 12
2007 / 11
2007 / 10
2007 / 9
2007 / 8
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 8
2006 / 7
2006 / 6
2006 / 5
2006 / 4
読者になる
広告を非表示にする
広告を非表示にする
広告を非表示にする
広告を非表示にする
広告を非表示にする
広告を非表示にする
広告を非表示にする
これ僕.com：行動分析学マニアがおくる行動戦略
Powered by Hatena Blog | ブログを報告する
このブログについて
谷口ジロー論を書いている
404
お探しのページは見つかりませんでした。
はてなブログ トップ
はてなブログ ヘルプ
月の生活 | よなよなエール公式ウェブサイト「よなよなの里」
読者になる
【今週のお題】暮らしていくなら、どこがいい？ 「住みたい場所」についてブログを書きませんか？
【5/24開催】技術情報のアウトプットをテーマにした「はてなブログ DevBlog Online Meetup」を開催します
“全世界に公開していいメモ帳”のスタンスで書くブログが誰かの助けになる【エンジニアのブログ探訪】
注目
洗濯
【衣類をキレイに長持ちさせたい】木村石鹸の石鹸洗剤「SOMARI」を１ヶ月間使って見ての感想。
少ない物ですっきり暮らす - 2021-07-07 06:00:01
料理
【レシピ】とろとろ茄子とピーマンの肉味噌炒め
今日は今が旬の茄子を使ったがっつりご飯が進む系レシピをご紹介します(*・〓・*)〓！ 甘辛い肉味噌が茄子に絡んで最高です〓 茄子は深めの隠し包丁を入れることで中まで火が通りやすく、トロトロに仕上がりますよ〓*。(〓〓〓*) それでは作り方をご紹介します(〓˘〓˘〓)* // とろと…
しにゃごはん blog - 2021-07-07 06:47:25
大丸さん
嫌な予感はしてたの。 なにせ、剛くんだからなぁ。もしかしたら...剛くんがゲストの名前覚えないのは自身も自覚はあるんだよね。インパルスをインパレス、 その板倉さんを坂倉さん。 沢尻エリカさんを桃尻さんでしょ 金田一先生を金田さん 高良健吾さんをたかなさん。 …
yumipon0524’s diary - 2021-07-07 06:37:38
10年代ブロガーがはてな村のおじさん達に思うこと
最近、はてなの長老方が今の「はてな村」について衰退を嘆いたり、悲しんだり、いやいや頑張ってるよと言ったり議論する様子を見た。 orangestar.hatenadiary.jp p-shirokuma.hatenadiary.com いっぽう、わたしはしばらくnoteにいったきり、はてなに戻ってない。そんな…
ゲーマー日日新聞 - 2021-07-06 21:59:25
医者の世界・健康ネタ
【おすすめ本紹介】「そろそろ、お酒やめようかな」と思ったときに読む本
おはようございます。 本日は、『「そろそろ、お酒やめようかな」と思ったときに読む本』という本のレビューです。 酒は百薬の長というのは昔の話であり、アルコール自体は飲まずにすめばそれにこしたことはありません。 私自身は元々お酒を大量に飲む方ではありません…
神経内科医ちゅり男のブログ - 2021-07-07 06:55:01
生活
206号室に、さようなら。
5年と3ヶ月住んだ部屋から、引っ越しました。 理由は一般的なところで言う「気分転換」です。引っ越すのは徒歩5分の近所。 ちょっと前は早く引っ越したい一心でしたが、長く住んだこともあり、最後の数週間は惜別の気持ちが募りました。 上京してからずっと住んでいた…
No.26 - 2021-07-04 23:41:56
CD店のこと
池袋西武の山野楽器が閉店すること
何かお店の話が続きますが、ニュースがだらだら出てくるので仕方がない。 今回は、山野楽器 西武池袋店が8月下旬で閉店するという話。池袋駅東口と山野楽器といえば、往年のレコードディガーな皆様ならみんな大好きパルコのオンステージ・ヤマノ。 外資系やWAVEが拡大…
WASTE OF POPS 80s-90s - 2021-07-06 00:47:27
出版社の編集者は何をする人なのか
かつては出版社の中に編集者という職業があって、著者に執筆を依頼したり、そうして書いてもらった原稿を取りに行ったり、誤字脱字や「てにをは」を矯正したり、漢字や送り仮名の表記を出版社のルールに従って統一したり、それを印刷製本する指示を出したり、そういう…
golden-luckyの日記 - 2021-07-06 12:58:47
ありがとう『ドラゴンクエストライバルズ』
ちょもすです。 ドラゴンクエストライバルズ エースは、2021年7月5日(月) 13:00をもってサービスを終了いたしました。約3年半にわたりご愛顧いただき、誠にありがとうございました！#DQライバルズエース(イラスト: @ArtePiazza より) pic.twitter.com/2nbbJNyS5p〓 ドラ…
chomoshのブログ - 2021-07-05 14:38:26
ふりかえりピックアップ
これが「わたしのプレイリスト」だ！ はてなブロガーたちによるプレイリストを集めました【今週のお題ふりかえり】
とっておきのプレイリスト、ありますか？多くの音楽配信サービスでは、誰もが気軽にプレイリストを作成することができます。この機能を使って独自のプレイリストを作ったり、聴いたりしている方もいるのではないでしょうか？そこではてなブログでは、今週のお題「わた…
アニメ
【幸福は創造の敵──】『映画大好きポンポさん』 劇場アニメ＆原作感想をまとめ読みしよう！
www.youtube.com 2021年6月4日から公開中の劇場アニメ『映画大好きポンポさん』。杉谷庄吾【人間プラモ】さんによる同名人気コミックを原作とするこの作品のキャッチコピーは、「幸福は創造の敵──」。 敏腕映画プロデューサー・ポンポさんのもとで製作アシスタントをし…
今週のはてなブログランキング〔2021年7月第1週〕
はてなブログ独自の集計による人気記事のランキング。6月27日（日）から7月3日（土）〔2021年7月第1週〕のトップ30です*1。 # タイトル／著者とブックマーク 1 大手金融機関から運用商品を買わない方が良い理由を金融庁が解説している - 銀行員のための教科書 by id:na…
わたしの偏愛
あのスーパーで流れている曲がどんだけガチか、夜通し語りたい。店内BGMにハマったら人生楽しくなった話【わたしの偏愛】
はてなブログは、「書きたい」気持ちに応えるブログサービス。ささいな日常や忘れらない出来事を綴るブログだけでなく、「推しへの思い」や「好きな映画の感想」「お笑いの分析」など、趣味や好きなものへの思いを言葉にするブログも数多く見られます。そこで、週刊は…
SmartHR とフルリモートワークと、時々、オフィス
こんにちは！CTO の芹澤です。 今回は SmartHR のプロダクトチームで行われているリモートワークの状況と、今後の働き方に関するお話です。 昨年度よりコロナ禍における暫定対応として採用されていたリモートワークを前提とした働き方について、そろそろ恒久的な方針を…
SmartHR Tech Blog - 2021-07-05 12:01:06
仕事
在宅ベテラン勢に、買ってよかった「在宅のお供」を自由プレゼンしてもらった【リモートワークアイテム連載 最終回】
長期にわたってリモートワーク（在宅勤務）を続けていると、仕事をする環境だけではなく、ストレスを解消するための工夫も必要になっていきます。家で快適に過ごすことも、在宅ワークでは大事ですよね。そこで今回は、長年リモートワークをしている“ベテランリモートワ…
ソレドコ - 2021-07-05 10:30:04
資産形成・投資
FIREで真に重要なのは早期退職ではなく経済的自立である
おはようございます。 最近、FIREという言葉を耳にすることが増えましたが、そのFIREとはFinancial Independence, Retire Earlyの略です。 前半部分のFinancial Independenceは経済的に自立すること、後半のRetire Earlyは文字通り早期退職を意味します。 もともとは、…
神経内科医ちゅり男のブログ - 2021-07-04 06:55:01
30代後半から40代の転職活動で気を付けること
こんにちは！ずんずんです。 30代後半から40代の方で転職活動してるけど「うまくいかないな〓」と思ってる方って結構多いと思うんですよね。 そんな方のために記事を書きたいと思います。 30代後半から40代の方って氷河期、ロスジェネで結構転職経験もあると思うんです…
ずんずんのずんずん行こう！改！ - 2021-07-01 15:29:35
GIGAスクール構想
【ゲーム禁止】教育委員会にScratchだけじゃなくGoogle検索も規制してもらおう！
Scratch禁止が多くなっている ＜ヒーローショーのノリで＞ やぁみんな！GIGAスクール構想で配付されたタブレットで、ゲームしてますかー！？ news.yahoo.co.jp 特にみんなにはScratchが大人気だよね！いろんなゲームで遊べるし。 …ん？ 「Scratchは、休み時間にやっち…
パパ教員の戯れ言日記 - 2021-07-04 07:58:57
3ヶ月の育休が終わって今日から復帰した
3ヶ月の育休が終わって今日から復帰した。 きのうの夜のうちにホットクックでカレーを作っておく 朝は6時半に起きた 洗濯機を回して干す パンを食べる ゴミをまとめて出したりダンボールを畳んだり 昼に食べる米の予約 子を連れて近所に散歩に行って喫茶店でコーヒーを…
hitode909の日記 - 2021-06-30 22:36:51
反インターネット論者としてのひろゆき
２ちゃんねる創設者のひろゆき（敬称略）がインフルエンサー２位になり、政府に助言したと話題になっている。賠償金云々の問題は脇に置いておくとして、なぜ彼があそこまでウケているのだろうか。 個人的に、ひろゆきは反インターネット論者だと思っている。ひろゆきほ…
メロンダウト - 2021-06-27
« お問い合わせ対応システム移行にともなう… はてなプライバシーポリシーの改定について »
はてなの各サービスの告知日記です。
読者です 読者をやめる 読者になる 読者になる
最新記事
携帯電話の回線を変更される方へのご案内
はてなプライバシーポリシーの改定について
はてなプライバシーポリシーの改定について
はてなIDのOpenIDサポート終了のお知らせ
はてなプライバシーポリシーの改定について
カテゴリー
はてなの日記 (632)
はてなアイデア日記 (600)
はてなグループ日記 (467)
はてなフォトライフ日記 (275)
人力検索はてな 日記 (254)
はてなアンテナ日記 (247)
はてなRSS日記 (241)
はてなカウンター日記 (167)
はてな使い方メールマガジン『週刊はてな塾』 (82)
はてなリング日記 (78)
はてなグラフ日記 (56)
はてなマップ日記 (42)
はてなロゴ日記 (32)
求人情報 (32)
はてなスクリーンショット日記 (19)
はてなグリースモンキー日記 (6)
月別アーカイブ
リンク
はてなブログ
ブログをはじめる
はてなブログPro
はてなブログをはじめよう！
hatenasupportさんは、はてなブログを使っています。あなたもはてなブログをはじめてみませんか？
はてなブログをはじめる（無料）
はてなブログとは
はてなの告知
Powered by Hatena Blog | ブログを報告する
ストック一覧を見る 閉じる
ログイン 閉じる
閉じる
限定公開記事のため引用できません。
読者です 読者をやめる 読者になる 読者になる
403 Error
現在、このページへのアクセスは禁止されています。
サイト管理者の方はページの権限設定等が適切かご確認ください。
はてなブログに引っ越し
2021.04.12
はてなブログに引っ越し
2021年4月から、2020年以降の記事を含めて「はてなブログ」に引っ越しました。今後もよろしくお願いします。
設計者の発言（はてな版）
«オブジェクト指向開発もローコード開発も楽しい
Powered by
August 17, 2013
本ブログは移転しました
[Web系]
新しいblogのURLはこちら。
http://f-shin.net/fsgarage/
10年前、2003年の8月に開始した当ブログですが、2013年8月に新しいURLに移行します。旧記事は、今のまま残しておきます〓
August 11, 2013
インターネットの遊び方を身につけよう
[Web系]
お馬鹿な写真をアップして問題になる件だが、はまちちゃんが書いていた、「Twitterがグループチャットに見える」というのは、その通りだと思ったが、かと言って、全く「うちら」の外側、見知らぬ人への
July 29, 2013
トトロが陽なら、『風立ちぬ』は陰？〜『風立ちぬ』の感想
[日常生活]
念のため、ネタバレ注意！
初日に映画は見終わっていたが、あんまり理解できなかった部分もあるので感想はfacebook程度でとどめていたが、以下の記事が素晴らしい考察だった。
July 28, 2013
「あ、安部礼司」果たして飯野っす君は結婚できるか？！
[日常生活]
TOKYO FM系列のラジオ局で日曜の夕方に放送されている「あ、安部礼司」。土曜夕方のアヴァンティが終わってしまった今、30代以上のリスナーにとっては、山下達郎のサンソンと同じぐらいの最後の希望であ
July 21, 2013
ネットでの選挙活動と投票率
[Web系]
どうやら投票率が低いらしい。なんというかネット選挙解禁とネットの人から見るかもしれないが、世の中的には参議院議員選挙の一つでしかないだろうから、衆議院議員選挙ほど盛り上がらないだろうし〓
July 19, 2013
システムがもたらす信頼を如何に作るか
[書評系評論]
信頼を感じた時に分泌されるホルモン「オキシトシン」というのがある。女性の分娩の時にも使われるこのホルモンは、本来は体内で分泌され、そのレベルがあがると気前の良い、思いやりのある対応をす〓
July 16, 2013
2013年からのWeb関連ビジネスの方向性と、「100万人から教わったウェブサービスの極意」kindle版 320円キャンペーンのお知らせ
[会社活動]
少し手元の作業が一段落した感があるので、今後のことを考える。今までWebのビジネスは、どちらかと言うとWebのビジネスだけに専念してきた企業がその利益を独占してきたと思うが、今後のWebは、それだ〓
July 09, 2013
3Dプリンターに対する単純な疑問
[会社活動]
身の回りの人たちが3Dプリンターを事業としてやり始めていて、まだ確実に早い行動だと思うが、とは言え、しかるべき時代が訪れた時に始めても遅いわけで、じゃぁ、どういう時代が来て、その時に3Dプリ
July 06, 2013
Web2.0がうまくいかなかったワケ
[Web系]
TBSの深夜番組で、人狼のカスタマイズ版であるジンロリアンという番組をやっていた。
普通の人狼とはルールが違う部分があって、
・人狼と疑わしきプレーヤーを排除するのを決定するのは視〓
July 05, 2013
愚問？ ＜ 緊急アンケート！安藤美姫選手の出産を支持しますか？ | お知らせ - 週刊文春WEB
[日常生活]
もはや社会的に責任をとっている【個人】を過剰に晒す行為というのは、何かの意図でもあったりするのでしょうか？！
緊急アンケート！安藤美姫選
June 27, 2013
DeNA南場さん「不格好経営」
[書評系評論]
若干ながら、いつからかDeNAの株を買って持っている。僕が買う株は、基本的に安定株だ。僕が言う安定というのは、変化し続けるネット社会の中で、自分たちがチャレンジをして新しい市場を作る期待がで
June 24, 2013
会社を辞めるまでの期間、1.5ヶ月以上は会社の甘え
[会社活動]
数少ない経験論かもしれないが、自分が会社を辞める時、もしくは周りや部下が会社を辞める時の経験を踏まえて思うのが、転職を決めて会社を辞めるまでの期間はどれぐらい必要か？！という話なのだが〓
June 23, 2013
スマホと携帯で違う所。
[モバイル系]
昔、iPhone売れないよねって言説に、iPhoneは入力が面倒くさいから売れないのがあった。
結果的には、これは半分あってて半分間違っていたようだ。どうやら正解は、iPhoneは売れたが、
「iPhoneは〓
June 13, 2013
Firefoxが実現するスマホのオープン化とガラケーエコシステムはHTML5で復権するか？！
[モバイル系]
「Firefox OSアプリ開発スタートアップマニュアルJune 12, 2013
エンジニアの評価が４以上にならないワケ
[会社活動]
エンジニアの仕事は原則として「できて100点」、できなければ減点。
一般的な社員評価の基準に照らし合わせると、「できて100点」だと、４以上の得点はつきにくい。
大体、どこの会社でもこ〓
May 25, 2013
WebにおけるMVCアーキテクチャの勃興と変遷
[Web系]
どんなに当たり前になった開発手法やプログラム管理方法があっても、新人さんにとってはHello worldから入って行くと思う。インターネットで、「知の高速道路」が整備されたと言っても、意外と古い話を〓
May 22, 2013
何故、PCはブラウザ、スマホはアプリなのか。
[Web系]
先に書いておきますが、このエントリーに強い主張も意図もありません。はてブでもtwitterでも見える所で、適当なツッコミなどいただけますと幸いです。
PCは、アプリよりWebブラウザ、スマホはWebブ〓
May 18, 2013
言っとくけどスマホは退化でもあるからな。
[Web系]
確かにiPhoneという名のタッチパネルパソコンは革命的に凄い。何より高性能でゲームもできるし、ボタンを意識しなくて使えるし、いろんな機能が割と自由に使える。
でも進化には必ず退化があって〓
May 16, 2013
コンピューター将棋には人間にあわせてバッテリーか何かの制約をもたせるべきでは？
[モバイル系]
高いレベルの人間同士の勝負というのは、「ミスをしないこと」が雌雄を決する。つまり、人間という基本構造が同じ者同士が、体力、技能、精神力、頭脳等を高めることで「ほんのちょっと他者より抜き〓
May 04, 2013
嫌な夢を見た
[会社活動]
嫌な夢を見た。いや、嫌な夢だったのかはわからないがアウトプットしてみる。
某メディア系大企業に就職した夢だった。
別にエライ人で入ったわけではなく、何かの部署の何かの一スタッフ〓
FAQ / お問い合わせ窓口
FAQ / お問い合わせ窓口
FAQ / お問い合わせ窓口
FAQ / お問い合わせ窓口
FAQ / お問い合わせ窓口
はてなブログ アカデミー
法人プラン
はてなブログ アカデミー
法人プラン
「livedoor 天気」は提供を終了しました。
アクセスされたURLは変更されました。
ブックマークを転送先のURLに変更してください。
自動的に転送しない場合 : こちらからブログへアクセスしてください。
クーポン大陸
CLOSE
キーワード
CLOSE
HOME
Hello! My Name Is 404
Hello! My Name Is 404
お探しのページはありませんでした。
クーポン大陸のTOPへ戻る
最近の投稿
Hello world!
最近のコメント
Hello world! に WordPress コメントの投稿者 より
© Copyright 2020 クーポン大陸.
クーポン大陸 by FIT-Web Create. Powered by WordPress.
©2020 IDEA*IDEA
〓〓〓〓〓〓0
〓〓〓〓〓〓0
〓〓〓〓〓〓0
〓〓〓〓〓〓0
〓〓〓〓〓〓0
〓〓〓〓〓〓0
Error. Page cannot be displayed. Please contact your service provider for more details. (28)
「最新トラックバック」は提供を終了しました。
「最新トラックバック」は提供を終了しました。
The requested URL was not found on this server.
Apache/2.4.29 (Ubuntu) Server at jp.kde.org Port 443
posted by yohei @ 20:53 1 comments
posted by yohei @ 13:13 1 comments
posted by yohei @ 06:26 0 comments
posted by yohei @ 23:40 0 comments
posted by yohei @ 07:08 1 comments
2000年から日替わりでドットコムを紹介しつづけた『100SHIKI』
金百利〓〓中心立志打造用〓体〓最佳〓〓平台,全天免〓提供快捷注册,金百利国〓〓〓在〓〓您提供国内〓尖的〓〓〓目,金百利〓〓网址〓〓你无限的激情!
如何〓运的方法，〓本命佛怎〓〓？〓本命佛是一个非常好的吉祥物，可以〓倒霉的人〓得运气好，运气好的〓就不管是做生意〓是日常生活，都可以一帆〓〓，而运气不好的人，就算是如日中天的事〓也会〓得不景气甚至破〓，平常生活中也会有〓多磨〓。金百利〓〓中心而那些〓了〓而不想〓婚，〓是因〓〓不算真正的成熟。金百利〓〓中心伶俐的外〓〓〓加上M运〓套件的加持使得其〓未上市便〓有了大量的〓〓。〓在很多都〓好的婚姻是要〓〓的，〓〓于夫妻来〓都是敏感的〓〓，很多女人比〓缺乏安全感，信奉男人有〓就会〓坏，所以在婚前都要求婚后丈夫的工〓要上交。
〓国策尼特 | 美国海普制管机 | 〓系我〓
〓于我〓
新〓〓〓
〓品中心
〓〓中心
客〓案例
〓售与服〓
人力〓源
〓国技〓
中国制造
〓看〓品
〓国原〓
免托板〓机
〓看〓品
〓〓与案例
公司最新〓〓
固〓〓〓只要60秒,省〓都来点...
建筑垃圾〓源化再生〓品在海〓...
泉工〓国策尼特参展2016卡塔〓...
了解更多
〓源〓合利用〓用案例
引〓〓国先〓技〓，研〓的〓渣〓粉制〓生〓〓可〓〓高〓振〓〓〓，合理地利用造〓〓程中〓粉〓粒互相〓合的原理。
了解更多
泉工〓国策尼特
中〓技〓融合
〓国生〓园区
〓国策尼特客〓案例
了解更多
成〓企〓〓接
〓品分〓
〓国策尼特〓〓
策尼特ZN系列〓〓
泉工QT系列〓〓
〓源〓合利用〓〓
加气混凝土生〓〓〓
水泥制管生〓〓〓
混凝土〓制构件自〓化流水〓
奥地利策尼特模具
〓系方式
福建泉工股份有限公司
地址：福建省泉州市丰州桃源工〓区
〓〓：+86-595-86789999 86784777
手机：+86-18105956852
〓系人：洪〓理
〓真：+86-595-86783988
〓箱：sales@qzmachine.com
全国免〓〓售〓〓：400 884 6789
全国免〓服〓〓〓：400 881 8789
企〓〓介 | 企〓新〓 | 〓系方式 | 〓ICP〓14008856号-3
Copyright (c) qzmachine.com. All right reserved.
404 Not Found： ページが見つかりません
▼【重要】ホームページ開設者の方へ▼
＠homepageは2016年11月10日(木)15時をもちましてサービス提供を終了させていただいたため、ホームページの表示ができません。
詳しくはこちらをご確認ください。
特定商取引法に基づく表示
©NIFTY Corporation
2018/2/8
PDFlib 9.1.2 と Block Plugin 5.12 が公開されました。
Forbidden
You don’t have permission on this
How to add PayPal to your website
How to accept epayments on your website
M-commerce is the new e-commerce!
E-commerce SEO tips for beginners
Web design inspiration: How to create a gorgeous portfolio website
How to make the most of Instagram for your business
Web design trends 2015: Simplicity and minimalism
E-commerce tips: Consumer psychology and the e-commerce checkout
E-commerce Solutions: What are your options?
Need free images for your website? Here’s where to find them!
Mobile web dominant over apps in retail
M-commerce in 2015 – three golden rules for marketers
Creating an HTML Email Newsletter – Video Tutorial
Please Parallax Responsibly: How to Join the Biggest Trend in Web Design Without Wiping Out
Technical skills required? What it’s like to spin up an online store now
2016-09-20
Seasar Conference Final
今週の土曜、9/24にSeasar Conference Finalを行います。
10年前に始まったSeasar Conferenceもいよいよ今度でFinalです。
お申し込みはこちら。
http://seasar.connpass.com/event/38679/
Seasar Projectの面白かったところって、開発方法論が盛り上がったところだと思うんですよ。
マーチンファウラーをはじめとして、著名な人たちのほとんどが「ドメインモデル推し」の中、僕は、「ステートレスなサービス + DTO推し」だったからね。S2Daoは、このために作ったようなものです。
あの開発方法論の議論に、かなりの人が参加したり、自分で考えたりしたでしょう。それが、面白かったところです。みんなが自分の事として考えたから。そんな難しい話ではないし、自分のプロジェクトに即いかせる話だしね。
オブジェクト指向ナンチャラとかDDDとか、素晴らしいものなんだけど、自分のプロジェクトで生かそうとするとそう簡単にはいかないからね。
Seasar2の開発が終了した事で、Seasar Projectに関わった多くの人たちの多くの時間が無駄にされたと、思っている人もいるようだけど、僕はそうは思わない。Seasar Projectに関わった事で、プログラマとしての能力や知名度をあげた人とって多い訳だから、それを否定する必要はないと思っています。
今度のSeasar Conferenceでは、「Seasar Projectのふりかえり」と「SXSW攻略法」の二つの話をします。
「Seasar Projectのふりかえり」では、昔話をしてもしょうがないので、いくつかのプロジェクトを「なぜ始めたのか」「うまくいったところとでその理由」「失敗したところとその理由」を話す事で、これから、新しくプロジェクトを立ち上げる人向けに、少しでも役に立つ話が出来ればと思います。
「SXSW攻略法」では、2016年のSXSWで、RealeaseItというアワードでファイナリストに残る事が出来たので、ファイナリストに残るためのこつ、そしてアワードをとれなかった理由。また、SXSWでは、ブースも出したので、ブースを出すときのポイントを話したいと思います。
Seasar Conference Finalお申し込みはこちらです。
http://seasar.connpass.com/event/38679/
このページはお客様のご都合により現在アクセスを休止しております。-This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required.
■015.004.008
[ EVENT ] 4月8日 Java Day Tokyo 2015 開催！
http://www.oracle.co.jp/jdt2015/
[ BROWSER ] Firefoxのページめくりを加速さ-http://journal.mycom.co.jp/news/2010/02/02/007/index.html
テンプレートがサーバサイドで実行される場合は、その時のModelやViewをクライアントサイドで復元するための情報も一緒にレンダリングします。これによって、ブラウザではあたかも最初からそこで動いていたかのようにBackboneアプリが動作することができるのです。ただし、この部分 (と、Modelのキャッシュ) はシンプルなRendrの中ではちょっとばかりトリッキーなところで、トラブルの元になりやすい印象です。アプリ内で画面遷移 (Router.navigate()) した後はうまく動くのに、リロードするとうまく動かない、なんて場合はそこら辺ではまってる可能性があります。
今までは純粋な技術書を読むことが多かったが、これからしばらくの間、プロジェクト全体を円滑に進めるにはどうすればよいかという観点から、何冊か本を読んでみるつもりだ。-自動車保険をネットで見積比較！ 契約者にはロードサービスご提供
技術 (123)
アイデア (17)
13/09/13 非エンジニアもGithubを使うべき12の理由
undefined method `sub!’ for :@secure:Symbol (NoMethodError)/usr/local/lib/tdiary/tdiary.rb:394:in `block in initialize’/usr/local/lib/tdiary/tdiary.rb:393:in `each’/usr/local/lib/tdiary/tdiary.rb:393:in `initialize’/var/www/tree/d/index.rb:30:in `new’/var/www/tree/d/index.rb:30:in `_main’/var/www/tree/d/index.rb:16:in `main’/var/www/tree/d/index.rb:116:in `’
VALUE-DOMAINならドメインが年990円！、サーバーが年2400円！
.
前 2013年
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
05/26 *終了* SEA Forum 『ソフトウェア技術者の「働き方」を考えよう！』 新宿歴史博物館 ２階講堂
05/07 *終了* SEA SPIN 『ソフトウェア・プロセスとは？』 港区生涯学習センター 3F 304学習室
04/13 *終了* SEA SPIN 『要求変更・追加に柔軟なプロセスを考える』 全国情報サービス産業厚生年金基金会館 7F B会議室
03/19 *終了* SEA SPIN 『プロダクトの品質とプロセスの品質』 新宿歴史博物館
03/06-07 *終了* SEA/FORCE 5th WS 〜ソフトウェア信頼性研究会 第5回ワークショップ〜 和歌山市
02/26 *終了* SEA Forum 現代の産学協同の形態に関する議論 Part 2 新宿歴史博物館
02/24 *終了* SEA SPIN Decade〜この10年でわれわれは何を得て，何を失ったのか？〜 新宿歴史博物館
02/06-07 *終了* SEA SQA WS 〜ＳＱＡは時代の変化と今の要請に対応できているか？〜 三島市
01/23 *終了* 〜ＳＥＡ新春教育フォーラム グローバルなソフトウェア技術者育成の課題〜 新宿歴史博物館
2008
12/11-13 *終了* SEA SPIN 浜松ワークショップ 浜松市地域情報センター
11/22-24 *終了* IWFST-2008 マカオ、中国
11/06-08 *終了* SEA 教育ワークショップ上海 上海市、中国
09/12-13 *終了* SEA 関西 SPIN WS ソフトウェア技術者の基礎力 近江八幡市
09/10 *終了* SEA Forum 産学連携の現在と将来−日本のソフトウェア産業の発展のために− 横浜市 神奈川近代文学館 会議室
08/22-23 *終了* SEA SPIN+SIGEDU WS プロセス改善 (SPI) 推進者のためのトレーニングとは？ 三島市
07/28 *終了* SEA Summer Workshop 2008 ソフトウェアの「かたち」を考える 前橋市 群馬会館２階 第６会議室
06/25-27 *終了* ソフトウェア・シンポジウム2008 かがわ国際会議場 & サンポートホール高松(香川県高松市)
06/05 *終了* SEA Forum これからのソフトウェア開発を考える 横浜市開港記念会館 ６号室
04/15 *終了* SEA Forum いま ソフトウェアが抱える諸問題 (Part-II) 新宿歴史博物館 ２階ホール
03/12 *終了* SEA Forum みずほ証券 vs 東証「誤発注事件」をめぐって 新宿歴史博物館 ２階ホール
2007
12/07 *終了* SEA Forum Immaterial Labor としてのソフトウェア開発 新宿歴史博物館 ２階ホール
10/29 *終了* SEA Special Forum 〜リチャード・ストールマン氏を迎えて〜 全国情報サービス産業厚生年金基金(JJK)会館 ２F ホール
10/11 *終了* SNS (Social Network System)を考える 新宿歴史博物館 ２階ホール
10/08-09 *終了* 第8回 ソフトウェア開発に関する国際ワークショップ 西江大学校 韓国 ソウル市
09/14 *終了* SEA Forum プログラミングにとって数学的思考は役に立つのか？ 新宿歴史博物館 ２階ホール
07/12 *終了* SEA Forum いま，ソフトウェアが抱える諸問題 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
06/27-29 *終了*ソフトウェア・シンポジウム2007参加者募集 新潟市 朱鷺メッセ
05/16 *終了* SEA Forum ソフトウェア開発の過去と未来 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
04/19-21 *終了* 坂本記念 SEA-SPIN ワークショップ 2007 朱鷺メッセ 会議室 新潟市
04/18 *終了* SEA Forum エンドユーザ指向の分散アプリケーション開発 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
03/20 *終了* SEA Forum プロセス vs プロダクト 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
02/23 *終了* SEA Forum ソフトウェア品質保証再考 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
01/26 *終了* SEA 新春教育フォーラム 2007: 教育ノウハウの継承と発展 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
2006
12/14 SEA Forum December: 「品質保証」および「技術者教育」についての連続パネル 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
11/28 SEA Forum November: フォーマルメソッドを品質保証に生かすためには何をすべきか？ 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
11/27 SEA International Forum November: 手法・プロセス・モデリング ハートピア京都（京都府立総合社会福祉会館）
10/30 SEA Forum October: オフショア開発の現状と課題 名古屋国際センター 3階 第二研修室
09/29 SEA Forum September: オフショア開発の現状と課題 全国情報サービス産業厚生年金基金（JJK）会館 7F 会議室
08/21 *終了* SEA Forum August: これからのシステム開発：要求工学の挑戦 全国情報サービス産業厚生年金基金（JJK）会館 7F B会議室
08/12 *終了* SEA & FSIJ 合同フォーラム 〜LinkStation/玄箱をハックしよう〜 つながれっとNAGOYA
07/19-21 *盛況にて終了* ソフトウェア・シンポジウム2006 熊本 ウェルシティ熊本
07/10 *満員盛況にて終了* SEA Forum July GPL v3 を考える 全国情報サービス産業厚生年金基金（JJK）会館 7F B会議室
06/17 SEA Forum June in Osaka アスペクト指向技術は実用に使えるか なんばパークスタワー 20F 会議室
06/16 *満員につき受付終了* SEA Forum June オブジェクト指向の理想と現実 全国情報サービス産業厚生年金基金（JJK）会館 7F B会議室
05/31 *満員につき受付終了* SEA Forum Special フォーマルアプローチはシステム危機を救うか？ 全国情報サービス産業厚生年金基金（JJK）会館 7F B会議室
05/17 *受付終了* SEA Forum アスペクト指向技術は実用に使えるか 全国情報サービス産業厚生年金基金（JJK）会館 7F B会議室
04/03 *盛況でした* Waterfall Model 再考（最高？）全国情報サービス産業厚生年金基金（JJK）会館 2F B会議室
01/27 第14回 SEA 新春教育フォーラム 東京都南部労政会館
2005
11/08-10 Call for Participation IWFST-2005 Shanghai
10/19 SEA FORUM October ソフトウェア工学の最新動向と将来展望 名古屋・伏見
07/14 G. Yamamura氏からSPI経験を通した知見を聞き、話す会 東京 （株）日立システムアンドサービス本社20F会議室
06/20 SEA FORUM ソフトウェア工学の最新動向と将来展望 東京 JJK会館
06/08-10 終了: ソフトウェア・シンポジウム2005 富山市 富山国際会議場
06/06-07 終了: ソフトウェア信頼性研究会第２回ワークショップ 富山市 富山国際会議場
03/23 SEA & FSIJ 合同フォーラム: 開発最前線シリーズ:ソースコード検索エンジンgonzuiの開発 東京都体育館 第四会議室
02/24 SEA & FSIJ 合同フォーラム: Internetから起動するKNOPPIX 東京都体育館 第四会議室
02/24-26 終了:デザインワークショップ DW2005 熱海市 ウェルハートピア熱海
2004
10/20-22 終了: International Symposium on Future Software Technology 2004 中国 西安
10/20-22 論文募集(*受付終了*): International Symposium on Future Software Technology 2004 中国 西安
09/03 SEA SS2005 Pre-Forum「組み込み系の最新技術動向」 富山市 サンシップ富山704会議室
07/10 SEA ＆ FSIJ 合同フォーラム 〜ミニ Wiki 祭り〜 東京 日本青年館
06/21-24 ソフトウェア・シンポジウム2004 岡山コンベンションセンター(ままかりフォーラム)
06/19-20 終了：ソフトウェア信頼性研究会キックオフワークショップ 大阪市 大阪大学中之島センター
06/19-20 終了：ソフトウェア信頼性研究会キックオフワークショップ 大阪市 大阪大学中之島センター
04/06 プロダクトライン・ソフトウェア工学の実践と課題 大阪市立大学 文
lockエラー
▽ 閲覧者様へ
ご迷惑をおかけしております。
サーバーを管理している Just-size.networks です。
現在、都合により閲覧が制限されております。
大変申し訳ございませんが、しばらく経ってからまたお越し下さい。
▽ 管理者様へ
アカウントがロックされております。
お問い合わせ窓口よりご連絡下さい。
© Just-Size.Networks レンタルサーバーサービス.
Posted by it_design at 16:27 │Comments(40) │TrackBack(0) │「 私 」
ワーキングマザーのオススメケータイブログ
ワーキングマザーのオススメケータイブログを紹介しています
オススメケータイブログ情報
超簡単ミニログ
全機種絵文字対応Blog感覚で動きのあるHPが
作成できる無料HP作成サービス「ミニログ」です
ママ限定
忙しいワーキングママにおすすめのサイト集です。
ぜひ覗いてみてくださいね
ワーキングマザーのオススメケータイ小説
明日なのか数万年後なのか600年前なのか、ベテルギウス爆発
地球からの距離は約６００光年とされる一等星ベテルギウスでこんな話題が舞い込んできました。
asahi.com（朝日新聞社）：ベテルギウスに爆発の兆候 大きさ急減、表面でこぼこ - サイエンス:
オリオン座の１等星「ベテルギウス」で、超新星爆発へ向かうと見られる兆候が観測されている。米航空宇宙局（ＮＡＳＡ）が６日に公開した画像には、星の表面の盛り上がりとみられる二つの大きな白い模様が写っていた。この１５年で大きさが１５％減ったという報告もあり、専門家は「爆発は数万年後かもしれないが、明日でもおかしくない」と話す。もし爆発すれば、満月ほどの明るさになり、昼でも見えるようになる。
冬の大三角の一つでもあるベテルギウスは、赤色超巨星と呼ばれる巨大な星。直径は太陽の１千倍で、太陽系にあるとしたら、地球や火星はおろか木星までが覆われる大きさだ。重いため一生は短く、まだ数百万歳（太陽は４６億歳）だが、すでに寿命に近い。最後は超新星爆発を起こし、ブラックホールなどになるとされる。
地球からの距離は約６００光年。
もし爆発すれば？明日でもおかしくない？数万年後かもしれない？だって600光年ですよ。光、電波いずれも地球に届くのに600年かかるわけだよね。仮に明日「爆発した！」となっても、それは600年前に起きた出来事がやっと地球に伝わったということ。爆発したのかどうかは、すでに結論は出ているかもしれない。これは面白い。どんだけ過去と現在と未来を自由に使ってるのかと。
遠い星の過去の歴史が届くのを待ちながら、自分たちの未来を予測する仕事なのですね。
ロマンを感じる、、といきたいところだが、むしろ背筋に冷たいものを感じる気がする。だって、地球に情報が届いていないだけで、宇宙的にはもう決まってるわけだし。
遠い星を調査する天文の専門家は、未来に向かって調査を進めているというよりは、過去にすでに起きた出来事が地球に届くのをひたすら待っているのですね。光よりも早いスピードで伝達するものを見つけられれば、もっと先のことまでわかるわけだ。おっと、「光速よりも先に伝搬し影響を及ぼす何かがある」とすると、観測して予測するより先にどがーんと影響を受けてしまう。
これは急がねばならぬのでは。光より速い、観測可能なものを早いところ見つけろ、と。
は、それがスーパーコンピューターで計算できたら世界一だねｗ
それはそうと、600光年って、まあ、思ったより近いしリアルな印象を受けました。ウルトラの星、M78星雲は銀河系から300万光年だからおとぎ話でいられるわけですね・・・。
は！ウルトラマンはどうやって移動するんだろう！？ウルトラマンは地球の平和を守るためにちまちま怪獣退治してる場合ではなく、むしろ宇宙で何が起きているのかを伝えるという仕事をしてくれたらいいんだよな。
スーパーコンピューターじゃだめだ、ウルトラコンピュータじゃないと！
「宇宙」が面白くなってまいりました。
30年に一度の「大きなツキ」の日。
国立天文台天文情報センター暦計算室によると、2010年の元旦は満月。
元日と満月の組み合わせは30年に一度だそうです（裏はとれず）。
追記：しかも！2010年元日の早朝に、部分月食が起こるそうです。
”2010年最初の月食は部分月食で、元日の早朝に起こります。食が始まるのは午前3時52分頃、終わるのは午前4時54分頃で、食の最大は午前4時23分頃となります。”
なにはともあれ、さまざまな景気循環説は数十年単位ですよね。
1980年代。オープン・イノベーションの担い手が大手企業のR&Dからベンチャーに移ったドラスティックな時代。音楽的には80’sは時代を超えてひとつの伝説化しています。フュージョンブームでもありましたね、コピーバンドの多さが支えました。
当時わたしはティーンエイジャーで、高専で、勉強も、バイトも、バンドも、好きにいろんなチャレンジをした時代でした。そう、もっと好きにやってもよかった。今？再びやってるんだなあ、そういうこと。
1990年代。生産重視系、焼き畑農業的ビジネスのバブルははじけるわけですが、技術革新のシードが大きく発展した時代。
わたしはOAの会社を経て、早くにUNIX系エンジニアに。とても早くにインターネットに接することができたためにLinuxとともに成長し、それをきっかけにさまざまな人の出会いやプロフェッショナルビジネスに恵まれました。
2000年代。IT・ネットバブルが一旦はじけ、競争力の源泉がめまぐるしく変化する時代。この10年をぜえぜえいいながら走ってきたわけですが、この時代にいろんな「起業」を体験し、そして末吉さんとか高須賀さんとか大前さんとか他にも大勢の「匠」、あとは不断の仲間を得、それぞれから常に学ぶ機会をいただいている。これはとても大きいと思います。
2009年、大勢の方々に力を得て今日までめちゃめちゃスリリングに過ごしました。公私ともに、いろんなバッターボックスに立たせていただけた。とてもとても感謝しております。
つらいことも、楽しかったことも、必ずいいことにつながります。逃げと失敗は本質的に違う。失敗に折れないことも、成功に甘んじないことも成長につながります。
2010年を迎える今、景気循環が何年単位でもいいんですけど、とにかくマクロ的弁証法的にも、ミクロ的体感的にも、原点回帰とステップアップの両方がどくっどくっと躍動が来てる感覚があります。そして、エンジニアリングふたたび。Emacs率急上昇中です。社会心理学の実装に没頭することにも決めました。
さあ、元日、「大きなツキ」を見よう。
あっさり1400+365文字まで書けた件
なにこれ、woofer? 英辞郎曰く、「低いうなり声[音]を出す」
そうするとここでは「つぶやく」感じではなく、ぶつぶつと好きなことを延々と言えというわけですね。あまり人として充実した感じはしないが、まあ人の言うことなんて自分にとっては名言だが聴き手にとってはうなってる程度なのかもだね。
このインターフェース、なにが一番のキモかってこの文字数カウンターだよね。Twitterでは、「あと何文字書けるか」を140から減じていく方法で表示させるのに対し、Wooferでは、「あと何文字書かなければならないか」を-1400から加算していく方法でひたすら「0」になるのを目指させる。
で、どれどれ、と書き始めると、なかなか1400文字も行かない。最初はこのページの雰囲気に引っ張られて、普通にtwitterぽく書いていくわけだが、少々長く書いたところで-1241とか書かれていて、
「あはは。おまえ、そんな程度しか文字書けないのかよ。ずいぶん体力落ちたな！ twitterなんぞで中途半端に情報メタボになっちまってるんじゃネーノ？（爆」と言われてる感じだ。「そりゃこのインターフェースの狭さのせいじゃないのかよ」と言ってみよう。この時点ではそう思った。
だってさ、私の場合、記事を書く場合はWordやWriteRoom(Mac用執筆ソフト)で書く。パワポでも、A3モードにする。そこには「書くべき内容をじゃんじゃん投げ込める広い面積」を確保し、遠慮無く書く。とにかく好き放題発散してもあとで俯瞰して編集し、自分のタイム感で「語りかけ」をする。広いってすばらしい。つまり、書くべきものにふさわしい広さとタイム感を持った入力先が必要だろう。
なんてのはどうかね。
「インターフェースの面積」 x 「インターフェースが強制するタイム感」＝「執筆空間」
twitterは面積が狭い上に、早いスピードを強制するから、それは直感的かつ短命な情報がじゃんじゃん現れるわけだが、なぜかしら執筆エネルギーをそいでしまうため、blogなど長文を書く頻度、あるいは書いたとしてもその量、質すなわちゆとりを持って彩りのある表現を存分に駆使することに元気がでなくなる。
広い面積のRHODIAや、3Mのイーゼルパッドで、ゆったりとした時間をとり、思考のマッピングをする人を何人か知ってる。プチアイデアを落としてしまわないために急いで書くことを怠るわけではないのだが、そういう「ちょっとしたレベル」の情報単位はポストイットやRHODIA#11を使う。Evernoteはそこに位置づけられる。
すなわち、Twitterではその「ちょっとしたレベル」で人とプチ情報の交換ができる、そういうことが起きていると思えるわけなのだが、そこでは連携性のある思考マッピングには向かない。短期記憶に収納するには大きすぎるし、せかせかとした情報フローでは立体的なビジョンを書き落とせないからだ。
ここに大きな思考表現の機会損失があることは明白だ。
どうすればいいか。少なくとも、利用のシチュエーションごとにばさっと切り替えるとか。いわゆるパソコンのキーボードを使うときは、ばっさりtwitterに書かないとか。思考マッピングできる「広い面積」の出番を減じないようにし、自分のはけ口に安易にtwitterを使わないことにする。ケータイやスマートフォンはいいとしよう。老若男女とせいぜい仲良くtweetしよう。
次に、twitterでは「タイム感」を落とす。これはfollowerを減らすか、スルー力をつけるしかない。follow数が劇的に少ない人に面白い発言者が多い気がする。要するに「タイム感」を強制されていないからかもよ。
1400文字書くのも、やってみると乗ってきますな。途中で息切れしつつも、乗ってくるとこの狭いインターフェースでも結構書けてしまう。楽々1400文字をクリア
■ Google、「Chromium OS」を公開
http://www.publickey.jp/blog/09/chrome_os.html
■ シャットダウンも日本語入力もできない?
http://blog.livedoor.jp/dankogai/archives/51325262.html
■ Chronium OSのコンパイル手順
http://d.hatena.ne.jp/showyou/20091120/1258687525
■ IBM developerWorks:Scitter(ScalaのTwitterクライアントライブラリ)を使ってTwitterを更新する
http://www.ibm.com/developerworks/jp/java/library/j-scala10209.html
■ IBM developerWorks:Web アプリケーションのセキュリティー: 脆弱性をテストする(WebScarab、Paros Proxyの紹介)
http://www.ibm.com/developerworks/jp/web/library/wa-appsecurity/
■ IE用のJavaScriptパフォーマンス分析ツール「dynaTrace AJAX Edition」
http://journal.mycom.co.jp/news/2009/11/20/017/index.html
■ YouTube:Lisp for High-Performance Transaction Processing
http://www.youtube.com/watch?v=xquJvmHF3S8-■ ブラウザ上で世界中のAM・FMラジオ、ネットラジオが無料で聴けるサイト「Streema」
（for PC & MOBILE）-何かくれ
| ニュース | サイトマップ |
2009.06.17 [セミナ情報]ＮＥＷ !!
6/30(火)に体験キャンペーンとして、ENdoSnipe無料体験セミナーを行います。こちらから申し込みいただけます。
2009.06.16 [Webセミナ] ＮＥＷ !!
技術トレンディセミナーにて、「第４回:次世代高速モバイル通信の最新事情」を公開しました。
2009.06.12 [WEBセミナ]
基本技術を学ぶWEBワークショップ『寺子屋会』の第12回解答、第13回問題を公開しました。
2009.06.10 [製品情報]
ENdoSnipe Ver4.0をリリースしました。詳細は、プレスリリースのページをご覧下さい。
ENdoSnipe Ver4.0の新機能については、新機能紹介ページをご覧下さい。
2009.06.05 [JTS]
JTS(Java TroubleShooting)にて、「オブジェクトの重複チェックに時間がかかってしまいます。」を掲載致しました。
2008年10月24日 ISMS認定を取得致しました。
2005年4月21日 国内最小規模・短期間(約1年)で達成しました。
livedoorホーム ｜ ヘルプ
livedoor Blog（ブログ）
ブログ障害につきまして
いつもlivedoorをご利用いただきありがとうございます。
現在、livedoor Blogが表示されないという障害が発生しております。
【障害内容】
・ブログが表示されない。
・ブログ記事が投稿できない。
【原因】
・通信機器の障害
【障害発生期間】
10/28（火） 18：35〜現在
現在ハードウェアの交換作業をおこなっており、復旧予定時刻は
10/29(水) 午前2:00前後を予定しております。
※今回の障害においてデータの欠損等はございません。
ご利用の皆様には大変ご不便をおかけし誠に申し訳ございません。
現在、メンテナンス対応中ですので復旧まで
今しばらくお待ち頂きます様お願いいたします。
利用規約 ヘルプ・お問い合わせ
Copyright (C) 1996-2008 livedoor Co.,Ltd. All rights reserved.
ウィンドウズ 開発統括部 ブログは MSDN へ引越ししました。
おはようございます。五寳です。
かねてよりアナウンスさせていただきましたように、ウィンドウズ開発統括部ブログは eXperts Connection (eXConn) から、MSDN へ引越ししました。
当面の間は、過去の記事の参照なども必要と思いますので、こちらのサイトも残しておきますが、最新の投稿は http://blogs.msdn.com/jpwin/ から発信されます。
それでは、今後ともよろしくお願いします。
コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時 2008/09/30 3:37 by ウィンドウズ開発統括部
Internet Explorer 8 Beta1 は、開発者向けにリリースされたものですので、通常利用にお-さて、午前中の Keynote の部分は Dean Hachamovitch が紹介したことはざっくり書きましたが、午後一であった Chris Wilson の ”Welcome to Microsoft Internet Explorer 8” について、紹介したいと思います。この Mix での Chris の公演は、おそらく Mix 終了後 MSDN か Mix のサイトで公開されると思いますが、ざっとこんなこと話したんだなーということが分か
Ajax blog
Ajax (Asynchronous JavaScript + XML) blog ■ Ajax に関する最新ニュースとリソース集 ■Ajax 関連の情報募集中 ■ yukio.andoh@gmail.com ■
自己紹介
名前: Yukio Andoh
場所: Kawasaki, Kanagawa, Japan
詳細プロフィールを表示
Previous Posts
Ajaxian 〓 Dojo 1.0 Released: The Granddaddy is Bor...
728 Ajax/Javascript/Dhtml examples and demos to ...
YUI Compressor 2.0
jQueryを使ってTwitterをおいしくマッシュアップ
Google Gears API Blog: Google Gears 0.2 developer ...
Google Web Toolkit Blog: Google Web Toolkit 1.4 Re...
Google Web Toolkit Blog: Google Web Toolkit 1.4 Re...
AjaxでFLVを制御するオープンソース「Flash-Ajax Video Component」
Ext JS Blog - 〓 Ext v1.1 Released
YSlow for Firebug
Archives
03.2005
04.2005
05.2005
06.2005
07.2005
08.2005
09.2005
10.2005
11.2005
12.2005
01.2006
02.2006
03.2006
04.2006
05.2006
06.2006
07.2006
08.2006
09.2006
10.2006
11.2006
12.2006
01.2007
02.2007
03.2007
04.2007
05.2007
06.2007
07.2007
08.2007
09.2007
11.2007
11.07.2007
Ajaxian 〓 Dojo 1.0 Released: The Granddaddy is Born
Ajaxian 〓 Dojo 1.0 Released: The Granddaddy is Born
posted by Yukio Andoh @ 11/07/2007 0 comments
9.21.2007
728 Ajax/Javascript/Dhtml examples and demos to download
728 Ajax/Javascript/Dhtml examples and demos to download
posted by Yukio Andoh @ 9/21/2007 1 comments
9.03.2007
YUI Compressor 2.0
%u300CYUI Compressor 2.0%u300D%u304C%u30EA%u30EA%u30FC%u30B9 - JavaScript%u3068CSS%u306E%u4E21%u65B9%u3092%u5727%u7E2E | %u30A8%u30F3%u30BF%u30FC%u30D7%u30E9%u30A4%u30BA | %u30DE%u30A4%u30B3%u30DF%u30B8%u30E3%u30FC%u30CA%u30EB: ”YUI Compressor 2.0”
posted by Yukio Andoh @ 9/03/2007 0 comments
9.01.2007
jQueryを使ってTwitterをおいしくマッシュアップ
jQuery%u3092%u4F7F%u3063%u3066Twitter%u3092%u304A%u3044%u3057%u304F%u30DE%u30C3%u30B7%u30E5%u30A2%u30C3%u30D7 %uFF081/4%uFF09 %u2500 %uFF20IT
posted by Yukio Andoh @ 9/01/2007 1 comments
8.30.2007
Google Gears API Blog: Google Gears 0.2 developer release ready for download
Google Gears API Blog: Google Gears 0.2 developer release ready for download
posted by Yukio Andoh @ 8/30/2007 0 comments
8.21.2007
Google Web Toolkit Blog: Google Web Toolkit 1.4 Release Candidate 2
Google Web Toolkit Blog: Google Web Toolkit 1.4 Release Candidate 2
posted by Yukio Andoh @ 8/21/2007 0 comments
Google Web Toolkit Blog: Google Web Toolkit 1.4 Release Candidate 2
Google Web Toolkit Blog: Google Web Toolkit 1.4 Release Candidate 2
posted by Yukio Andoh @ 8/21/2007 0 comments
8.02.2007
AjaxでFLVを制御するオープンソース「Flash-Ajax Video Component」
CodeZine%uFF1AAdobe%u88FD%u3001Ajax%u3067FLV%u3092%u5236%u5FA1%u3059%u308B%u30AA%u30FC%u30D7%u30F3%u30BD%u30FC%u30B9%u300CFlash-Ajax Video Component%u300D%uFF08%u30A2%u30C9%u30D3%uFF09
posted by Yukio Andoh @ 8/02/2007 0 comments
Ext JS Blog - 〓 Ext v1.1 Released
Ext JS Blog - 〓 Ext v1.1 Released
posted by Yukio Andoh @ 8/02/2007 0 comments
ライフハックやGTDのための動作の軽いPDAが欲しい
IRのお手本-やらない理由はこれだけで十分 (デイトレード、“必敗”の理由 (板倉雄一郎の『真っ当な株式投資』))