データエンジニアリングにおけるAI活用戦略：縦と横のハーネスエンジニアリング
AIが力を発揮できるように周辺環境を整備するエンジニアリングのことを「ハーネスエンジニアリング」と呼ぶらしい。*1
- AIがBigQuery MCP Serverを経由してBigQueryにアクセスし、データを解釈できるようにしたり
- データ不整合に関する調査ドキュメントを読み取り可能なコンテキストの中に配置し、過去の調査結果を参照できるようにしたり
- AIがログ・メトリクスを閲覧して、エラー探知から修正を行うループを回せるようにしたり
ハーネスエンジニアリングの出来によりAI利用による生産性は大きく変わるのを、最近は実感している。
ハーネスエンジニアリングは、データエンジニアリングの領域を労働集約から資本集約の構造へ変えるポテンシャルがある。
- （外部からのイメージに反して）データエンジニアリングの仕事は実に労働集約的だ。
- 例：
- 既存のSQLで変な箇所を調査する→労働集約的だ
- dbtで書かれたSQLを変更する→労働集約的だ。コンパイルが通るのを確認し、SQLFluffが通るのを確認し、データ上の変更をチェックする。
- BIに記述された指標定義を確認し、変な箇所がないかを確認する→労働集約だ。個々の作業に高い技量はいらない
- 人間からの問い合わせを理解可能な言語に落とし込む→あまりにも労働集約的だ。人間が言語を習得するより、AIが言語を習得する方が早かったのは、人間の知能の限界を示す良い例だろう
上にあげた操作の一つ一つはAIにより代替可能である。従って、複合的な動作もAIにより代替可能である。
AIに対する環境の整備は資本の蓄積だ。一度整備した権限はずっと使えるし、Agent Skillが忘れられることはないし、人間と相性が悪いから使えなくなるわけでもない。資本を蓄積し、労働集約故のコストを乗り越えたいと思い、最近はハーネスエンジニアリングに取り組んできた。
contradiction29.hatenablog.com
一度振り返り、知見を書き留めておきたい。
2つの方向性
「ハーネスエンジニアリング」の概念は未成熟だ。しかしデータエンジニアリングの分野に絞れば、ハーネスエンジニアリングの方向性は大きく2つに分けられる：
- 縦方向のハーネスエンジニアリング：AIが活用できるデータの流れの範囲を増やす
- 横方向のハーネスエンジニアリング: データから恩恵を受けられる人間の数を増やす
詳細を書いていく。
縦方向のハーネスエンジニアリング
データが従うライフサイクルは、ざっくり言えば以下のような流れになる。
データの発生 → データの保管 → 加工 → 集計 → 表示
この流れのうち、AIが把握できる「流れ」の範囲を拡大するのが「縦方向」だ。
- プロダクションのコードに対するアクセスを行うことで、データ収集を行うロジックにアクセスできるようになる
- BigQuery MCP Serverなど、DWHへの直接アクセスをする
- dbt MCP Serverで変換ロジックをAIが辿れるようにする
dbtやBigQuery、あるいはTableauなどは、公式・非公式を問わず公式のMCPサーバーやAgent Skillが存在していて、権限上の懸念を解消できれば簡単に実現できる。Looker Studioなど、CLIどころかAPIが存在しないBIは面倒だが、Playwrightなどのブラウザ操作系のツールを使って、BIの画面を探索させ、データソースや指標の定義をメモとして書き出す方法がある。
縦方向のポイントは、データソースから最終的なBIまでの全体の流れをAIが一貫して辿れる状態を作ることだ。個別のMCPサーバーやAgent Skillを繋ぎ合わせ、複合的な動作を構築する。環境が整備できれば、ミーティング中に指摘された指標のずれについてその場で対話的に解決！のようなこともできるようになる（なった）。
横方向のハーネスエンジニアリング
データに関する知識をスケールアウトさせ、恩恵を受けられる人の数を増やすのが「横方向」だ。プロダクト方面のエンジニアリングとは異なり、非エンジニアに対して影響を発揮できるデータエンジニアリング分野特有の方向性になる。
まだ取り組みが浅く、知見が溜まっていないが、方向性だけ書いておく
- BtoB SaaSの場合、顧客に導入効果を出す必要がある。顧客と実際に向き合っている営業やカスタマーサクセスは、指標の定義を理解し、効果改善のサイクルを回す必要がある。彼らに向けた知識の提供経路としてAIを使うことはできる。エンタープライズサーチと接続し、データの知識を提供する
- PdMや他のエンジニアなど事実に基づく意思決定のサイクルを回す
- Devinなどを使い、Claude Codeなどローカルでの環境構築が必要な形態から脱する
おわりに
AIによるトレンドは確定的だ。「AI時代にエンジニアは生き残れるか？」などの転職サイト運営業者が好きそうな浅い議論をする意味はない。重要なのは、実際に仕事に取り組んでいる人間が、「AIがやるのと人間がやるのと、どちらがマシか？」を問いかけることだ。コメンテーターがあなたの仕事をなんとかしてくれるわけはない。
目の前の仕事を改善するのは、その仕事に取り組んでいる人間がやるのが一番確実だ。
人手不足ホワイトカラーにおいて、AIは光となるだろう：ハーネスエンジニアリングをやれ
他人をコントロールすることはできない。
- 他人を自分の思い通りにしようとすることは傲慢であり、倫理に反する
- 何より不可能である
- 他人の内面を知ることはできない
- 共感と呼ばれる行為は、大抵の場合は思い込みか自己投影であり、背景事情への理解を諦めた人間が苦し紛れに行う自己正当化のための理屈に過ぎない
社会人を始めて数年経てば、大抵の人間が行き着く結論だろう。ここまではいい。
問題は、行き先を失った期待をどこに向かわせるかだ。
自分なりに考えてみたが、「仕組み」に対して期待を寄せるのが良いのではないか、と最近は考えている。
- 仕組みは100%完全にコントロールできるわけではない。住んでいる国家は生まれる前から存在していたし、世界はr > gである
- だが、人間よりはコントロールが効く
- 仕組みを通じて、人の行動を変容させることはできる
ところで話は変わるが、人間を育成し、パフォームできるようにする過程には、往々にして不確実性が伴う。
- 人間には感情がある。感情があるが故にロジックは曲がり、言語化不可能・理解も不可能・再現性のない領域が出来上がる
- 人間には関係性がある。目的の実現より関係性を優先する場合もある
- 人間には離職のリスクがある。育成したとて、離職するのなら、目的の実現には意味がない。
つまりは不確実性が大きく、投入した時間と労力は成果に直結しにくい。経験がある人も多いだろう。
僕も何回もある。データエンジニアを育てようとしたが、結局何にもならなかった。当人のキャリアの方向性と合わなかったり、適性がミスマッチだったり、僕と当人の性格が合わなかったり、理由はそれぞれだ。当人にはなんらかの影響を与えたかもしれないが、「（業務上の）成果」と呼べるものではないことは全て共通している。
一方、Claude CodeやDevinをはじめとするAIの育成はどうか。AIが暴れ回ることができるように環境を整えるエンジニアリングは「ハーネスエンジニアリング」と呼ばれ、このハーネスエンジニアリング次第でAIが実現できる成果は大きく変わる。
- AIの動作は、設計により改善することが可能である。AIが操作しやすい環境を作ることができれば、生産性は大きく向上する
- 人間の育成と比較するとどうか？
- ノウハウを言語化できれば、再利用可能な形で技術をスケールアウトできる
- スケーラビリティの観点を加えると、対比の構図はどうなるか？
- 再現性も高い
- 考えてみてほしい。人間の育成に再現性があると思うか？
- Agent Skillsは業務フローを言語化しているようなものではないか？
- 完璧な手順書を作ったとしよう。人間に与える場合と、AIが実行する場合と、どちらが良いだろうか？
何より、AIによる代替を徹底的に進めることは、既存の仕組みを破壊することにつながるのではないか？
自分なりの答えは出た気がする。AIがエンジニアを代替するか否かはどうでも良く、自分がどうするかだけが問題なのだろう。
AI使いこなしマンは土から生えてくるわけではないのが問題としては残っている
日記2026-02-10 : 共感の対象が目の前の人間に及ばない
人間に共感するのは難しい。共感能力がないわけじゃないんだ。共感の対象に、なんというか... 逆の遠近法のようなものが働いているのを最近は感じている。
凄惨な事件の報道を目にした後は心が痛む。だが、目の前にいる人間は「共感」の対象にならない。事件の報道を聞いた時に発動する共感が、目の前の人間からのお気持ち表明で一切発動しない。「（目の前にいるこの人は）何を言っているのだろう？」となる。
つまり、以下の2つのことが嫌なわけだ。
- 当人にとっては大事なことであると推測される「お気持ち」を、自分では一切理解できないこと
- 見知らぬ誰かが被害に遭った凄惨な報道に対しては共感ができるのに、目の前にいる人間に対しては共感を発動できないこと
悪意は一切ないんだ。原因は純然たる無能であることは理解している。物心ついた時からこんなふうだったように思える。
どうすればいいのか？
日記2025-02-08 : 言葉が意味を失ったんだ
口先だけであればなんとでも言える自信がついてきました。任意の主張を支持するか、支持しないするか、理由をどうとでも述べられる能力がついてきたのだと思います。
ロジックは世界観から演繹されています。賛成のロジックの中で、あるいは反対のロジックの中で、世界観を矛盾なく築き上げれば良い。世界観がロジックとなり、人の行動を決定する作用を働かせるのが実態です。「ロジックで説得するのではなく、ロジックを生み出す世界観を持って説得する」ーこの視点は、成果の高い営業マンの話し方を観察して、最近自分で編み出した視点です。世界観は前提条件で決まります。世界観＝前提条件と言っても良いでしょう。大事なこととして、前提条件がロジックに現れることはありません。
理由はロジックであり、前提条件から演繹されています。であるならば、真に突き詰めるべきはロジックではなく、ロジックが基づく世界観のはずです。しかしほとんどの人は理由＝ロジックだけに注目し、ロジックの前提条件に重大な齟齬があることを見逃してしまいます。気がついていたとしても、注目することは難しいでしょう。なぜならば、世界観は宗教的・哲学的な観点を多分に含むからです。「無難な話題」の対局である、大いに宗教的・大いに哲学的な議論をする能力と気力があるでしょうか？
重大な結論が出てきました。議論を「円滑に」（自分が意図する通りに）進めるためには、世界観の部分に工夫を入れれば良いのです。議論の参加者は鈍重な議論を避けようとして、世界観の部分にツッコミを入れてくることはないでしょう。あるいは、気が付かないかもしれません（私が試して見た限り、この方法はかなり有用でした。あまりに有用すぎたので、今はこの方法を可能な限り使わないようにしています。）
では、言葉の意味とは何でしょうか？私には何が何だかわからなくなってしまいました。どうとでも言いようがある言葉の世界に、意味はあるのだろうか？任意に操作可能な論理体系は、任意のロジックを表現可能です。つまり、何も意味もないのです。どうとでも言えるのであれば、何も言っていないのと同じです。
言葉の対局には「力」があります。持っている力を行使し、現状を変えることは、明らかに言葉の対局にあるでしょう。「話し合い」と「力の行使」の2つの選択肢がある中で、どちらをどのような理由で選ぶのかを検討する必要があります。
2026年もがんばるぞい！
22026年の決意表明のようなことをやっておきたい。2026年の終わりに見返すことで、今年は微妙だったのか、良い年だったのかを見分けることができるだろうと考えてのことだ。決意は書いておくに限る。
まず、去年の試行錯誤の結果として生まれた生き残り戦略を着々と実行していきたい。
- 健康が第一である。何よりも健康が大事だ。
- 金策をうまく回して、セーフティネットを作る。金の余裕は心の余裕
- 社交をやる。すでにあるつながりを大事にする。新しいつながりを模索しにいく。
丁寧な暮らしも欠かさずにやっていきたい。
- 家具をちゃんと買う。今までは機能を満たす最低限のものだけ設置すれば満足だったが、この状態から脱却していく。花瓶と花を買い、部屋に花を飾る。
- 地元をしっかりと楽しむ。近所の美術館や科学館、おいしいご飯屋、観光スポットなどには行っておく。
- 新しいことにチャレンジする。ボルダリングや格闘技など、新しい運動を始めてみたい。
エンジニアとしてのキャリアも高めていきたい。
- 技術と政治・エンジニアリングに対する理解を深め、定期的にアウトプットを出していく
- インプットもちゃんとやる
- 英語力を高めていく。海外のエンジニアと議論できるくらいまでに持っていきたい。
などなど。2026年も頑張っていきましょう！
2025年を振り返る
2025年を振り返る際に、まず振り返りのやり方を検討した。振り返りのhowについては、テキストデータを自然言語処理・あるいは単純な統計処理に基づき機械的分析を行う手法と、文字通りに年末に何があったかをRetrospectiveに振り返る「単純な振り返り」の手法の両極端があるだろう。まず機械的分析をやってみたが、去年の結果とほとんど変わらず、つまらないと思ってしまった。かといって単純に振り返るだけでは、後ろの期間に相対的に強いバイアスがかかり、直近あったことばかり振り返るようになってしまう。
2025年末の今回は間を取り、BigQueryに格納した日記のテキストデータをBigQuery MCP Serverを用いてGemini CLIで取得し、トピックを抽出して分析することにした。話題の抽出はLLMの力を借りつつ、その話題に振り返る価値があるかどうかは人間が判断するわけだ。メモのテキストデータも統合すれば、関心を持っていたトピックの情報がより強く浮き彫りになる。
そんなこんなで、2025年も様々なことがあった。記憶と記録を振り返り、まとめ、来年の糧にしていきたい。今の俺は、人は忘れる生き物であることを理解している。
引っ越した
（画像は千葉市美術館にある旧千葉市中央地区市民センターの模型）
2025年の12月に、東京の杉並区から千葉市中央区に引っ越した。
引っ越しにより月々の支払いは20%削減され、部屋の住みやすさは2段階くらい上がった気がする*1。ジムやスーパーも近く、東京特有の過密に悩まされることもない。東京へのアクセスは離れてしまったが、用事がある時は気軽に行ける距離だ。何より電車に乗らず生活に必要な動作を全て完結させることができるのが良い。
新しい家ではもっと住みやすくしたい。旧居は機能を最低限果たす家具しか置いておらず、寂しい感じになっていた。テレビ台は歪み、テーブルは汚く、ソファは存在しなかった。インテリアを自分でチョイスするセンスはないと実感している。ココナラでデザインと家具のセレクトを全部やってくれるサービスを見つけて、依頼してみたりした。まだカーテンしか買えていないが、いい感じの部屋を作っていきたい。リラックスできる環境を作りたい。
生存戦略の構築
個人レベルの生存戦略を構築するために必要なことは2点ある：
- 自分を理解すること。自分がどのような人間で、何が得意で、何が苦手で、何が絶対に無理なのかを把握する。
- 制約条件を理解すること。r > gが支配する現代においては、個人の努力により改善できる範囲には限度がある。
生存戦略とは、自己理解と制約条件の理解を前提とした、優先度に基づく判断基準である。2025年は自己理解が進み、制約条件の把握が進んだことで、生存戦略の構築を進めることができた。
一番大事にしていたのは健康だ。なんとしてでも健康を保つのは最優先目標だ。睡眠・運動・食事の3つをバランスよく回せればなんとかなる。
- 週に3回ジムに通うのをずっと続けることができた。ベンチプレスの重量は年初の40kgから最大70kgまで増量できた。最近はトレッドミルでの有酸素運動が楽しくなり、2-1インターバルを始めたりしている。
- 自炊もよく回るようになってきた。ホットクックを買ったり、レシピ本を買ったり、AIにレシピ相談をしたり色々やっていた。
金策もやっていた。一時個別株取引やクリプトのアルゴリズム・トレードに手を出した時期もあったが、今は単純な積立をずっと続けている。金に余裕があると心に余裕ができて良い。
社交は昔から苦手だ。苦手なりにうまくやる方法としては、他人から誘われるのを待つのではなく、自分から誘えば良いのだと気がついた。誘えば意外と乗ってくれる。今のところ断られたことがない。
肉体の健康を保ち、金策で余裕をつくり、社交を楽しんでいければ、生き残ることはできる。
仕事の話
前職では主にデータエンジニアリングをしていた。去年(2024年)の9月に今の会社へ転職してきたのを機にキャリアを変え、それ以来1年、主にアプリケーションのエンジニアとしてTypeScriptをカキカキするのが主な仕事だった。働き方としてはIC (Inidividual Contributor) にあたる。一転して、今年の10月から正式にデータエンジニアリングの仕事に就くことになった。ICからユニットのリード職となり、役割も変わっている。過去にやっていた仕事に戻ってくるのは「強くてニューゲーム」という感じだ。この分野の仕事は面白いと思うし、向いているのだろう。
とはいえ過去の反省もある。率直に言って、過去の自分はリーダーシップ不足だった。向き合うためにTwitterで見かけた『90日で成果を出すリーダー』を読み、書いてあることをずっと実践していた。
現実と向き合うためには、技術力に加えて政治力を身につける必要があると痛感した。政治から逃れることができないのなら、正面から実力でねじ伏せるのが王道だろう。ちょうどよくエッセイを見かけたので、決意を込めて翻訳もした。
技術力だけではどうしようもない状況にどう向き合っていくかが今後のテーマになるだろう。
おわりに
2025年は現実と向き合い、選択をし、自分なりの生き方を確立した時期だった。2026年はその生き方でどれだけ戦えるかを試す年になるだろう。来年も頑張っていきたい。
*1:全体で何段階あるかは不明だが、体感として2段階くらいである
データエンジニアとして合理的意思決定過程のスケール・アウトを目指す
人間と社会をしていると、「あなたは何の仕事をしているんですか？」と聞かれる場面があるだろう。普段関わりがない人と仕事をする時とか、自己紹介する必要がある場面とかで。気転を聞かせて、パッと「こういう仕事をしています」と言えるとカッコいいなぁ、と思う。
自己紹介の場面じゃなくても、普段から自分が何のために働いているかははっきりさせたい。目的がはっきりしないと、手段と目的を取り違えたりしてむず痒い気持ちになる。
データ関係の仕事に携わるようになってそこそこ時間が経った。最近は「僕は人々が合理的に意思決定するための仕組みを作っているんですよ」と説明するようになった。可能な限り多くの人が、迅速に、合理的に意思決定できる仕組みを作る。相手がエンジニアなら「合理的な意思決定のプロセスをスケールアウトさせている」と説明したりする。
Snowflakeを導入したり、SQLを書いたり、BigQueryを触ったり、BIを作ったり、Terraformを書いたりするのは、どう転ぼうと手段の域を出ない。昔は手段と目的を混同してしまうこともあったが、はっきり分けたほうが良いことは自明だろう。
話のポイントはこうだ：
- 可能な限り多くの人々にリーチする仕組みを作ること
- 地位によらず、可能な限り全ての人間が事実に基づく意思決定を行える環境の方が、限定された人間しかデータが見えない世界よりも良いと信じる
- 「仕組み」を作ること
- 仕組み化され、多くの人がデータを分析できる環境の方が、人手に頼ったデータ分析しか行えない世界よりも良いと信じる
- 高速にPDCAを回す仕組みを整えていく
- データ分析を高速に行い、より短いサイクル・タイムを提供できる世界の方が、長く時間がかかる世界よりも良いと信じる
エンジニアではない人々にもわかるような言葉を選び、説明することができれば、対外的な説得はしやすくなる。「政治から逃げるな」の一つの答えではある。言葉選びを考えるだけで政治的な協力が得られ、事を円滑に進められるのなら、随分とコストパフォーマンスの良い投資ではないだろうか。
自分がやっているのが合理的意思決定過程のスケール・アウトであると考えると、BIツールにおける認証の話と、SQLの話と、AIエージェントの話が同じ直線上に繋がってきたりする。
- BIツールにおける認証において、アカウント発行プロセスが長大であるより、すでに社内で利用しているGoogleアカウントで利用できるようにした方が絶対良い。アカウントの発行プロセスもスケーラビリティには影響する。
- データ加工用のSQLを整備し、使いやすいデータマートを作ろう。可能ならそのSQLは公開して、リネージを追えるようにしよう。
- 最良のデータ提供の形態がBIとは限らない。AIを通じた対話でデータ分析をする道のほうが、スケールはするのかもしれない。
目的がはっきりすると、非常に楽しい。
