職務経歴書

清水 直也

リードエンジニア/Platform・SRE

基準日
2026.08.30
GitHub
https://github.com/43z708
経験ポジション
  • Lead Engineer/Engineering Management
  • Platform/SRE・Cloud Infrastructure
  • Kubernetes/IaC・GitOps
  • Blockchain Validator Infrastructure
  • Web Application Engineering

職務要約

Webアプリケーション開発を経て、現在はAWS/Kubernetes基盤を専門とするPlatform/SREのリードエンジニアです。現職ではシニアエンジニア5名を率い、数十チェーンのバリデータ(ブロックチェーンの検証ノード)の運用統制と、Kubernetes/ベアメタル基盤の設計・実装を担っています。更新情報をAIで自動収集する仕組みで対応漏れをほぼ解消し、外部監査では指摘64件のうち63件の是正を主導しました。並行する業務委託では、生成AI基盤のEKS標準化と1,000人規模の突発負荷対策を設計・実装しています。

代表実績

  1. 署名鍵を分離した署名基盤を含む、EKS/ベアメタル上の3種類のバリデータ基盤を構築

    機密データ処理・署名・専用サーバー運用の3種類のワークロードに対し、AWS EKS/Kubernetesとベアメタルを要件に応じて選択しました。署名鍵をアプリケーションから分離し、約200鍵のバリデータ、約6,400 ETH相当のステークを支える署名基盤をEKS上に構築しました。

  2. 数十チェーンの更新運用を仕組み化し、対応漏れをほぼ解消

    5名のチームを率い、複数の連絡経路に分散していた更新情報をAIエージェントで自動収集・通知する基盤を立案し、実装・導入まで主導しました。ダブルチェックとGitHub Releases監視を残した多層防御により、情報収集に起因する対応漏れをほぼ解消しました。

  3. 約1週間を要していた預かり資産(TVL)集計・報告を毎日の自動投稿へ移行

    経理担当が1回あたり約1週間を要していた預かり資産(TVL)の集計・報告を、毎日の自動投稿に置き換えました。

活かせる経験・強み

技術統制・運用マネジメント

更新情報の自動収集と多層監視の仕組みを立案・設計し、数十チェーンの対応漏れを防止しています。稼働状況・作業残量・チェーン別採算を踏まえて要員配置と技術構成を決められます。

Platform/SRE

EKS/Kubernetesとベアメタルを選び分け、Terraform/Argo CD/AnsibleでIaC・GitOps化しています。Prometheus/Grafanaの監視から冗長化、更新・復旧まで設計・実装できます。

AI活用・業務自動化

静的サイト運営、記事生成、日報作成、TVL集計をAIで本番運用に組み込み、反復作業と品質課題を解消しています。

職務経歴

株式会社Omakase

2023.12 — 現在

入社以来、バリデータ事業の運用統制、Kubernetes/ベアメタル基盤の設計・実装、AIによる業務自動化までを継続して担当しています。事業継続に直結する運用判断から自ら手を動かす基盤構築、業務フローの改善までを一貫して担っています。

バリデータ事業の運用統制・セキュリティ推進

2023.12 — 現在

概要

ノードソフトウェア(クライアント)の更新の遅延が停止と収益減に直結する環境で、アップタイムを事業の生命線に据え、運用判断とセキュリティ対応を横断して担っています。

背景・課題

バリデータはブロックチェーンネットワークの運用に参加し、安定稼働に応じて報酬を得る仕組みです。クライアントを規定日までに更新できないと停止し、アップタイムの低下がそのまま収益減少につながります。しかし更新・設定変更の告知はDiscord、Telegram、Slackなどに分散していました。人手確認・ダブルチェック・GitHub Releases監視を重ねても、数十チェーン規模では見落としが事業リスクとして残っていました。同時に、多くのバリデータ選定でSOC 2 Type IIの取得有無が確認される事業環境のため、外部監査への対応も並行して必要でした。

本人の判断・行動

運用体制

個人の注意力や特定のメンバーだけが持つ知識を組織上の単一障害点と捉え、手順、監視対象、判断基準、対応履歴を共有・標準化しました。担当者へ調査・実装の裁量を委ねる一方、優先順位、技術判断、レビュー、最終判断は私が担当しています。メンバーが不在でも業務を継続できるようにし、稼働状況・作業残量・チェーン別採算も、要員配置および技術構成の判断に反映しています。

仕組みによる統制

2026年初頭にAIエージェントによる更新情報の自動収集・通知基盤を立案し、要件定義と設計方針を示したうえで実装は担当者に委任し、成果物のレビューを担当しました。ダブルチェックとGitHub Releases監視を残した多層防御とし、Cosmos系では再利用可能な構築テンプレートを整備しました。監視対象と通知経路の棚卸しも主導しています。

監査対応

SOC 2の外部監査に対しては、指摘事項を技術評価・環境別の適用判断・優先順位付けのうえで是正・適用除外・代替統制に分類し、是正状況のレビューを主導しました。

結果

導入後は、更新情報の見落としに起因する対応漏れがほぼ発生しなくなりました。外部監査の指摘64件のうち63件を是正し、残る1件はリスク受容として承認を得て収束させました。

技術環境

運用・統制環境

  • 監視: Prometheus/Grafana/CloudWatch/オンコール
  • 情報源: Discord/Telegram/Slack/GitHub Releases/AIエージェント
  • テンプレート: Cosmos validator template
  • コンプライアンス: SOC 2 Type II/Vanta(コンプライアンス管理SaaS)/ISO 27001

Kubernetes/ベアメタルによるバリデータ基盤設計・運用

2024.12 — 現在

概要

3種類の高可用性ワークロードについて、要件整理、アーキテクチャ設計、IaC、監視、セキュリティ、更新・復旧までを一貫して担当しています。AWS EKS/Kubernetesを共通基盤としながら、高い処理性能が必要な領域ではベアメタルを採用し、可用性・性能・運用性の観点から実行基盤を選び分けています。

背景・課題

ワークロードごとに、機密データを保護しながら行う計算処理、約200鍵のバリデータを支える署名、コンテナを使えない専用サーバー運用という異なる制約がありました。同時に、安定稼働には構成変更、監視、機密情報と設定の同期、更新、復旧を、手作業に依存しない再現可能な運用に揃える必要がありました。

本人の判断・行動

EKS/Kubernetes標準化

機密データを保護して処理するワークロードをAWS EKS上で標準化し、周辺リソースもTerraformでIaC化してArgo CDによるGitOpsに統一しました。変更はPull Requestでレビューできる状態にしています。PrometheusのメトリクスをAMP(Amazon Managed Service for Prometheus)/Grafanaに集約し、CloudWatchも含めて監視を標準化しました。段階的な更新、バックアップ、障害切り分け、復旧までをDay 2運用(本番稼働後の継続運用)として実装しました。

高可用・セキュアな署名基盤

約200鍵のバリデータ、約6,400 ETH相当のステークを支える署名基盤をEKS上に構築しました。署名鍵をアプリケーションから分離して集中管理し、AuroraとS3を正本とする多層防御、設定の自動同期、ローリング更新を実装しました。多数の署名処理、設定変更、障害時の切り替えを検証してから本番へ移行しました。

ベアメタル基盤のIaC

コンテナを使わず専用サーバーの性能を直接引き出す要件に対し、サーバーリソースをTerraformでIaC化しました。OS・ディスク・ミドルウェア・systemd・監視・更新処理はAnsibleでIaC化しています。事前に同期した次期サーバーへ処理を順序立てて切り替える更新手順も実装し、構成の再現性と停止時間の抑制を両立しました。

結果

GitOps・統合監視・バックアップ・復旧を備えたEKS基盤を構築しました。運用中に発見したTerraform moduleの修正提案は、すべて開発元に採用されました。ベアメタル基盤では、実運用の更新時にも再同期による停止をほぼゼロに抑えました。

技術環境
  • 基盤: AWS EKS/Kubernetes/Aurora/S3/ベアメタル
  • IaC・デプロイ: Terraform/Argo CD/Ansible/systemd
  • 監視: Prometheus/AMP/Grafana/CloudWatch
  • 運用: GitOps/Blue-Green更新/バックアップ・復旧

AI駆動の業務自動化・企業サイト刷新

2023.12 — 現在

概要

企業サイト、記事制作、日報作成、TVL集計に残る反復作業と品質課題を洗い出し、AIを単発利用で終わらせず、継続的に動く本番の業務フローとして設計・実装しました。

背景・課題

WordPressはAI支援で記事を継続生成する運用と相性が悪く、日報は手入力のため記録漏れや内容の希薄化が起きていました。TVLの集計・報告にも長時間の手作業が残っており、個人の記憶と作業時間に依存する業務フローそのものを見直す必要がありました。

本人の判断・行動

サイトと記事制作

WordPressを廃止してAstro/TypeScriptの静的サイトに刷新し、日本語・英語のコンテンツをMarkdownとしてGit管理へ移行しました。記事制作では調査、構成、執筆、レビューを分担するAIエージェントを組み合わせ、最終確認は人が行う生成工程を構築しました。

日報と集計

GitHub、Slack、Notion等の業務履歴から日報の下書きを生成・記録するBotを実装し、各自は確認・加筆に集中する運用に変更しました。TVLは算出に必要なデータを決定論的に収集・集計し、結果を毎日自動投稿する仕組みを本番導入しました。

結果

サイトと記事をMarkdown/Git中心で更新できる基盤へ移し、AI生成と人のレビューを両立しました。日報の下書きが業務履歴から自動生成されるため、チームの日常的な入力工数はほぼ不要になりました。TVLでは、経理担当が1回あたり約1週間を要していた集計・報告を、毎日の自動収集・投稿に置き換えました。

技術環境

技術・業務環境

  • サイト・コンテンツ: Astro/TypeScript/Markdown/Git
  • AI: Codex/Claude/AIエージェントのオーケストレーション
  • 業務連携: GitHub/Slack/Notion/Python

本業と並行する業務委託

生成AI基盤案件(社名非公開)

2025.12 — 現在

PMから提示された抽象的な依頼を技術要件に具体化し、生成AI基盤の調査、設計、実装、検証を一貫して担当しています。PMは各案件の要件・受け入れの最終判断とレビューを担います。

生成AIアプリケーション向けEKS標準基盤の再設計・横展開

2025.12 — 現在

概要

複数のDify Enterprise案件で再利用できるEKS標準基盤を、AWS CDKのPoCからTerraform/Fluxベースへ再設計し、社内外3環境へ展開しました。

背景・課題

引き継ぎ時点では、既存のCDKによるPoC実装という状態でした。複数案件でDay 2運用を続けるには、案件ごとの差分と変更影響をレビュー可能な形で管理する必要がありました。

本人の判断・行動

IaCと機密情報管理

長期運用と複数案件への展開を見据え、宣言的な差分管理、remote state/locking、PRレビューを重視してTerraformを採用しました。機密情報は導入当初からAWS Secrets Managerを正本とし、External Secrets OperatorでKubernetesに同期しています。この構成により、Helm valuesに機密情報を残さない運用を実現しました。

GitOpsと運用設計

外部ベンダーが管理するHelm Chartを安全に更新し続けるため、Argo CDではなくFlux HelmReleaseを採用しました。自社管理のChartであればArgo CDを優先できますが、Difyでは外部Chartを継続的に取り込むため、Chart側で将来追加されるHookのライフサイクルを自社で制御できません。過去にpre-install Jobがupgrade時にもPreSyncとして実行され、finalizer滞留でApplication全体が止まった経験があります。そのため、Helm本来のinstall/upgradeの挙動を維持する方式を選びました。自社固有のDB初期化は外部Chartから分離し、独立したKustomizationと冪等Jobとして管理しています。

可観測性と変更統制

Prometheus stack/Grafanaを導入し、dashboard JSON/PromQLをGit管理して、毎朝9時のTerraform planでドリフトを検知しています。staging適用の承認とE2E自動テストも組み込み、安全に更新できる運用フローを整えました。

結果

3環境への展開

社内環境に適用し、別の受注案件2件でも基盤として活用されています。前提が揃う1件では設定値と手順書により約0.5人月相当の構築を1日に短縮し、もう1件ではCDKで実運用中の案件をTerraformへ移行するための基盤として利用されています。

技術環境
  • 基盤: AWS EKS/Terraform
  • GitOps: Flux HelmRelease/Kustomization/External Secrets Operator
  • 監視・CI: Prometheus/Grafana/GitHub Actions

突発的な1,000人負荷に備える生成AI基盤の性能・コスト最適化

2025.12 — 現在

概要

「普段はコストを抑えた構成とし、災害時などの突発利用にはAuto Scalingで追従する。最大1,000人規模の突発負荷を測定し、成立性をレポートする」という要求がありました。これを試験仕様に具体化し、ボトルネックの調査から改善実装、再検証まで担当しました。

背景・課題

Auto Scaling

LLMの生成待ちを含む長時間処理では、短時間に多数の要求が入ると処理待ちが既存のインフラ指標に表れるより先に積み上がり、必要容量の判断に遅れが生じました。

DB接続

同時に、ワーカーが長時間処理の間も接続を保持し、PostgreSQL backend接続数が負荷の上限要因の一つになっていました。

本人の判断・行動

Auto Scaling

Auto Scalingは、CPU使用率やALBリクエスト数ではなく、処理待ち件数から必要台数を直接決める方式にしました。CPU target trackingは需要の先行指標にならず、ALB RequestCountもCloudWatchへの反映とタスク起動を待つ必要があるため、いずれも不採用としました。代わりにCeleryのactive/reservedとRedisのqueuedを読むサイドカーを実装し、需要を10秒ごとにカスタムメトリクス化しています。需要低下時だけ直近300秒の最大値を保持する方式(peak-hold)をExactCapacityに反映しています。

DB接続

DB接続のプーリングには、RDS ProxyではなくPgBouncer transaction modeを採用しました。RDS Proxyを実機検証したところ、16 KBを超えるSQLによるセッション固定(session pinning)が発生していました。加えて多数のidle backendも残り、Difyの大容量insertでは接続多重化が効きにくいと判断しました。PgBouncerのtransaction modeはSQLサイズに依存せずtransaction終了時に接続を再利用できる点が選定理由です。API/ワーカーのlocalhostサイドカーとして実装しています。

結果

1,000人規模の突発負荷

外部LLM/APIを、実測した応答特性を再現するモックに置き換え、1,000人・10分rampの総合負荷試験を実施しました。主要APIが目標水準に収束するまでの時間を11〜12分から約6分に短縮し、負荷中の早すぎるスケールインも防げることを確認しました。

DB接続数を約65%削減

PgBouncer導入前後を同じ負荷条件で比較し、PostgreSQL backend接続数を5,473から1,928に、約65%削減しました。

平時コストと拡張性の両立

平時は月額約1,450〜1,750ドルに抑えつつ、1,000人規模まで拡張できる構成にしました。同等の高負荷構成(Aurora min 16 ACU×2など)を常時固定した場合の試算は月額5,000ドル超です(検証時の構成とAWS単価に基づく)。

技術環境
  • 基盤: AWS ECS/ALB/CloudWatch/Aurora PostgreSQL
  • Auto Scaling: Celery/Redis/カスタムメトリクス/Step Scaling
  • DB接続: RDS Proxy/PgBouncer transaction mode/負荷試験

過去案件

生成AI議事録ツール

2023.06 — 2023.10

PoC/個人開発(単独担当)。企画から実装・運用まで担い、実際の利用では生成後の確認・修正作業を約60〜90分から約10分に短縮しました。

コミュニティ向けBot

2023.02 — 2025.11

コミュニティ運営ツールの設計・開発・運用保守を担当しました。

大規模BtoB人事サービス

2022.06 — 2024.04

BtoB SaaS/業務委託(フロントエンド担当)。CTOの段階移行方針に対し、Vue 2/Reactが共存できるqiankunを選定しました。

ナビゲーションのReact置換まで実装し、契約終了時に後任へ引き継ぎました。

URL共有サービス

2021.08 — 2022.04

Webサービス開発(フロントエンド・バックエンド担当)。本サービスの設計から相互レビューまで担当しました。

業務SaaSのリニューアル

2021.03 — 2021.07

SaaSリニューアル(フロントエンド・バックエンド担当)。機能開発とテストを担当しました。

業務Webアプリ

2020.11 — 2021.07

業務システム開発(API・管理画面担当)。詳細設計、API・管理画面開発、テスト、環境構築を担当しました。

オンラインイベント基盤

2020.03 — 2021.02

個人学習PoC(単独開発)。WordPress中心だった時期にWebアプリケーション開発を学ぶため、設計・開発・デプロイ・試用まで行いました。

技術スタック

Cloud/Platform
  • AWS(EKS、ECS、Aurora、AMP、S3、Secrets Manager)
  • Terraform/Ansible
  • Argo CD/Flux/Helm/Kustomize
Observability/Reliability
  • Prometheus/Grafana/CloudWatch
  • 負荷試験/Auto Scaling
  • GitHub Actions/ドリフト検知/review gate
Application/AI
  • TypeScript/React/Vue
  • Python
  • 生成AIを用いた業務自動化

自己PR

私の強みは、想定ではなく実際に検証した結果と現場の制約を起点に技術を選ぶことです。業務委託先の生成AI基盤では、DB接続にRDS Proxyを実機で検証し、大きなSQLで接続の再利用が効かなくなる挙動を確認したうえでPgBouncerに切り替えました。Auto Scalingでも、需要に遅れて反応するCPU使用率ではなく、処理待ち件数という先行指標から必要台数を決めています。その結果、1,000人規模の負荷試験でDB接続数を約65%削減し、主要APIが目標水準に収束するまでの時間も11〜12分から約6分に短縮しました。

もう一つの強みは、個人の記憶や注意力に依存する業務を、仕組みとして回る形に設計し直すことです。現職では、特定のメンバーだけが知る手順や判断基準をチームの共有資産に変え、各担当者に裁量を委ねながら優先順位と最終判断は私が持つ形で運営しています。反復作業にはAIを継続的に動く業務フローとして組み込み、日報は業務履歴からの自動生成に変えて各自の入力工数をほぼ不要にし、記事制作も人の確認を残した生成工程に置き換えました。業務委託では、PMの抽象的な依頼を段階負荷と目標水準を定めた試験仕様に具体化し、実装・検証まで一貫して担当しました。

これらの強みは、少人数で広い範囲を運用し、技術判断と実装の両方が求められるチームで特に活きると考えています。5名のシニアエンジニアに裁量を委ねながら最終判断を担う経験と、要件の具体化から設計・実装・検証まで自ら手を動かす経験の両方を持っています。判断の根拠を検証結果で示し、運用を属人化しない仕組みに落とし込むことで、チームの意思決定と本番運用を前に進められることが、私の提供できる価値です。