--- title: "Charlie Tang Hoong — 応用 AI・自動化エンジニア、マレーシア" url: https://cv.tanghoong.com/ja/ locale: ja description: "マレーシア・セランゴール州を拠点とする応用 AI・自動化エンジニア。15 年以上の経験で、曖昧なビジネス課題を本番稼働する AI・自動化・ソフトウェアに落とし込みます。マレーシア、シンガポール、アジア太平洋地域に対応。" --- # Charlie Tang Hoong **FDE ── 応用 AI・自動化エンジニア** — マレーシア・セランゴール州 · UTC+8 曖昧なビジネス課題を、本番で動き、効果を測れ、運用し続けられる AI・自動化・ソフトウェアに落とし込みます。 15 年、拠点はマレーシア・セランゴール州です。その仕事の多くは同じかたちで始まります —— 他人が書いたシステム、ドキュメントはなし、そして直すあいだも事業は止められない。 ## 裏づけ - **3 件中 2 件は「やめましょう」** — 異なる 3 分野の AI 実現可能性評価。うち 2 件は設備投資が見合わないと判断し、実施しないことを提案しました。3 件目は構築しています。 - **月間数十億インプレッション** — 担当したアドテク基盤の規模です —— 毎秒数万リクエスト。私が作り直したバックエンド経路では p95 が 100 ミリ秒を下回っています。 - **パイプライン 15 本以上** — 価格モニタリング、リード獲得、市場情報 —— 中小企業向けに構築。求められていたのは価格表を見張る仕組みであって、プラットフォームではありませんでした。 - **15 年以上** — 4 社、シンガポールでの業務委託 1 件、2 度の起業、そして個人での受託 —— 相手は大企業の運用チームから 2 人の中小企業まで。 その 3 件の AI 提案のうち 2 件は成約しませんでした。そこが要点です —— 顧客は十分に早い段階で実際の数字を手にし、安いコストで「やらない」と判断できました。 ## 主な実績 5 つの事例を同じ形式で書いています：顧客が何をしようとしていたか、何が不明確だったか、私が何を決めたか、何を作りまたは助言したか、そして結果どうなったか。 - 事例 1 — 自分たちのものではないシステムの上で開発する: 複数の役割にまたがる予約・注文プラットフォームを、大企業顧客の旧来 ERP の上で本番稼働させました。インターフェース契約は顧客側のエンジニアと直接取り決め、範囲の変更はすべて開発に入る前に書面で承認を得ています。 - 事例 2 — 止められない帳票業務から、入力作業をなくす: OCR と LLM を組み合わせたパイプラインで、大量の海運帳票業務における手入力を大幅に削減しました —— 元システムには API がなく、置き換えることもできない運用環境で。 - 事例 3 — 接続を占有せずに、AI アシスタントの負荷をさばく: AI カスタマーサポートのリクエスト経路を作り替えました：1 回の会話は同期接続を占有するのではなく、キューに入りフロントエンドがポーリングする方式へ —— 納品・マージ済みです。 - 事例 4 — AI の提案 3 件、うち 2 件は「やめましょう」と伝えた: 異なる 3 分野での AI 実現可能性評価。いずれも解決策の設計と費用を含む構築見積もりを出しました：うち 2 件は設備投資の観点から正しく見送られ、3 件目は構築しています。 - 事例 5 — 土台となる開発力：数十億インプレッションと、自走するマーケットプレイス: 同じアドテク企業での 2 期・計 11 年：4 年はプラットフォーム刷新でただ 1 人のフロントエンドエンジニア、続いてセルフサービス型の広告マーケットプレイスをゼロから構築、そして毎秒数万リクエストを支えるバックエンドです。 ## 仕事の進め方 相手が大企業の運用チームでも、2 人の中小企業でも、同じ 7 つのステップです。順序のほうがツールより重要です —— 私が見てきた失敗の多くは、最初の 1 行を書く前に決まっていました。 - **01 把握** — 実際にその作業をしている人の隣に座り、業務が本当に動いているとおりに記録します。組織図が説明するとおりにではありません。本当に重要なことは、たいてい要件書には書かれていません。 - **02 定義** — 新しい業務フローを図にし、関係者と一緒に確認し、開発着手前に書面で合意します。何が対象外か、何を意図的に第 2 フェーズに回すかも明記します。 - **03 設計** — 何を買い、何を作るかを先に決めてから、どう作るかを決めます。買える部分は組み込み、重要な経路は自分で作り、そして本当の制約に正直に向き合います —— ネットワーク、権限、他社のリリース周期、これ以上増えない予算。 - **04 構築** — 複雑な部分と、インターフェース契約を決める部分は自分で持ち、単純な画面は任せます。一つのタスクが 30 分たっても方向が定まらなければ、黙って作り直すのではなく設計の議論に切り替えます。 - **05 展開** — この環境は自分では変えられない前提で進めます。侵襲的でないやり方で組み込む —— すでにあるところから読み、長い処理にはチェックポイントを置き、中断したら最初からではなく途中から再開し、そして人が途中で引き継げる経路を必ず残します。 - **06 計測** — 「正常」とは何か、それをどう見えるようにするかを、あらかじめ決めておきます —— リトライの挙動、失敗の見えやすさ、1 リクエストあたりのコスト。AI であれば、印象ではなく評価データセットで測ります。 - **07 改善** — 今回の範囲を納め、次に必要な前提条件を見えるままにしておき、そのうえで本番が明らかにした事実に優先順位を決めさせます。 ## 提供できること - **顧客の要件把握と提案定義** — 課題を抱えている本人と直接やり取りします —— 運用担当者、創業者、顧客側のエンジニア —— 不完全な要望を、範囲が明確で、金額があり、「完了」の定義が共有された提案に変えます。これは両側から経験しています：事業会社の内部では業務プロセス担当としてドキュメントのない経理・物流の業務を図にし、外部のエンジニアとしては AI システムを買ったことのない中小企業の案件評価を行いました。 - **応用 AI と業務自動化** — 実際の業務のなかで動く必要がある AI です：帳票からの項目抽出と、書き込み前の人による確認工程。カスタマーサポート AI の知識構成、ツール呼び出し、会話管理、有人への引き継ぎ。そして経理と物流にまたがる、もともと手入力だった RPA。 - **ソリューション設計と基幹システム連携** — つながる前提で作られていないシステム同士をつなぎます —— 顧客の旧来 ERP、API のない元システム、外部の EC・決済プラットフォーム、メッセージキュー、そしてその間に挟まる人手の工程。繰り返し出てくる判断は「買うか作るか」で、私は両方を十分な回数やってきたので、本当に面白い問いがどこにあるかを知っています：どの制約が「買ってきた部品」を成立させなくするのか。 - **本番運用と信頼性** — 動き出したあとも、責任は私にあります。長い処理は最初からではなく途中から再開します。失敗は、人がまだ手作業に戻せる時点で表に出します。キューで処理し、遅い 1 件が次の顧客を待たせないようにします。送信は冪等にし、再読み込みで二重に走らないようにします。使われていないリソースは、抱えたままにせず解放します。 - **技術デリバリーと関係者調整** — 私が率いるのはデリバリーと技術判断であって、人数ではありません：チームの意見を聞いたうえでの最終的な設計・技術選定の決定、チームが実際に従うコードレビューの運用、そしてエンジニアが本当に詰まっている場所から引き出すこと —— 私の経験では、それはほぼ必ずコードではなくインターフェース契約です。