株式会社パブリックテクノロジーズ、略してパブテクは、「Japanese Dynamism—地域から世界へ、日本を躍動させる」をビジョンに掲げ、GovTech・AI領域から社会の仕組みそのものをアップデートする挑戦を続けています。

そんなパブテクで、開発を担う技術開発部。自治体や地域事業者向けのプロダクト群である住民向け行政スーパーアプリ『パブテク』、自治体AIアシスタント『パブテクAI行政』など、複数のプロダクトを同時に推進しながらも、スピードと将来の拡張性を両立させています。

生成AIなどの最先端技術を柔軟に取り入れつつ、人が向き合うべき設計や検証にはしっかり時間を使う技術開発部。スピードと品質、その両方を追求するためにどのような工夫や考え方を大事にしているのか。

今回は技術開発部マネージャーで、テックリードの大橋芳生さんにお話を伺いました。

技術開発部 エンジニアリングチーム マネージャー/テックリード 大橋芳生

目次

1. 少数精鋭で、スピードも将来設計も両立するパブテクの技術開発部とは。
2. 生成AIが「土台」を作る。その分、人間は「本質」に集中する。ポストAI時代の開発とは。
3. 行政の“当たり前”を自分たちでつくる。パブテク技術開発部の次なる挑戦。

少数精鋭で、スピードも将来設計も両立するパブテクの技術開発部とは。

── まずは、大橋さんのこれまでのキャリアについて教えてください。 

大橋さん：
エンジニアとしてのキャリアは、今年で約10年になります。

受託開発会社で3年間ほど幅広い案件に携わったのち、個人事業主として約2年間フリーランスで活動していました。

そこから楽天グループの「ラクマ」に移り、ゆうパケットポストの導入をはじめとした配送領域のプロジェクトを担当しました。その後はLINEヤフーで、ショッピングの配送系プロジェクトに携わり、主にリファクタリングや運用改善に取り組んでいました。

1年ほど前に、CTO森宮のリファラルでパブテクにジョインして、以前から興味のあった官公庁・自治体領域のサービス開発に、技術開発部のテックリードとして携わっています。

── 技術開発部はどのようなチームなのでしょうか。

大橋さん：
パブテクが展開する、行政と地域を支えるGovTech事業において、その名のとおり技術開発を担うチームです。

メンバーは5〜6名の少数精鋭で、フロントエンド、バックエンド、フルスタック、SREなど、それぞれ異なる専門性を持ったエンジニアが集まっています。

ここにPdMとデザイナーが加わり、プロダクトを構想から実装まで一気通貫で進めているようなチームです。

── 大橋さんは、テックリードとしてどのような役割を担っているのでしょうか。

大橋さん：
構造設計・技術選定・コードレビューから、業務フローの把握と仕様設計まで、技術に関わる意思決定を全般的に担当しています。

住民向け行政スーパーアプリ『パブテク』や自治体AIアシスタント『パブテクAI行政』など、複数のプロダクトが同時に動くパブテクでは、それぞれ背景も要件もまったく異なるので、将来の拡張に耐えられる設計になっているか、現場で本当に活用される仕様になっているかを見極めながら、検証と調整を積み重ねる必要があります。その中核を担うのが、僕の役割だと思っています。

── パブテクの技術開発部のテックリードとして、どんなところに面白さを感じていますか？

大橋さん：
一番の面白さは、多くの企業だと一部の限られた技術者しか取り組めないような最先端技術を用いた開発領域まで、一から作れるところですね。

たとえば『パブテクAI行政』では、生成AIをただ動かすだけでなく、自治体特有のネットワーク制約の中で「どう運用可能な形に落とし込むか」を念頭に設計しています。ただ、このあたりはまだ世の中に標準解がない部分が多い領域です。

そこを紐解きながら、僕たちなりに今つくれる最善の解を形にしていく挑戦には、パブテクだからこそ得られる面白さがあると感じています。

── たとえば、どのようなことですか？

大橋さん：
自治体向けに生成AIシステムを設計する際、最初に直面したのはモデルやプロンプトの問題ではありませんでした。最大の壁は、LGWAN（*1）を前提とした情報系ネットワークの制約そのものです。

LGWAN環境では、外部APIへの直接通信が制限されていたり、ファイル添付の上限が数MB程度に抑えられていたりと、一般的なクラウド前提のアーキテクチャがそのまま通用しません。
たとえば、職員さんが「この資料をAIで要約してほしい」と思っても、元データが5MBを超えるだけで送信できず、処理自体が始まらないケースがあります。

こうした制約を無理に回避しようとして、 「ファイルサイズを小さくしてください」「別の方法で送ってください」 と運用で吸収してしまうと、結局は現場の負担が増えるだけです。そこで私たちは、ネットワーク制約を前提条件として受け入れた上で、処理の流れそのものを組み替えるアプローチを取りました。

▼ こうした制約との向き合い方については、テックブログでも詳しく紹介しています。
『LGWAN環境のファイルアップロードでハマった話と、Yak Shavingを避けるための実践的アプローチ』

https://zenn.dev/pubtech/articles/lg-wan-restricted-file-size

生成AIというとモデル選定やプロンプト設計に注目が集まりがちですが、自治体領域ではそれ以上にネットワーク制約とファイル運用ポリシーの壁をどう越えるかが肝になります。つまり、生成AIのアルゴリズムよりも前段にある通信・ファイル処理レイヤーそのものを“行政仕様”に再設計する必要があるということです。

ただ、こうした技術的な回避策を講じるだけでは不十分で、生成AIの動き方そのものを行政の業務環境に適応させる必要があります。現場の文脈を理解していなければ、生成AIは正しい答えを返せません。

「この文脈で求めているのは、本当にこの回答なのか？」
「職員の方が探したいファイルを、どうすれば最短で見つけられるのか？」

行政業務の解像度と、生成AIの再現性の両方を満たすためには、技術面と業務面の双方を噛み砕く橋渡しの設計が欠かせない。

ネットワーク制約やファイル運用ポリシーといった行政特有のルールを尊重しながら、生成AIが最大限能力を発揮し、現場で使われる構造をどう作るか。その両立を試行錯誤し続けることは、難しくもあり、この領域で開発する大きなやりがいだと感じています。

（*1）LGWAN（総合行政ネットワーク）:自治体・公的機関が相互接続する全国統一の閉域IPネットワーク。外部インターネットと論理分離され、認証・監査・脆弱性対策の基準を満たすシステムのみ接続可能。行政事務の電子化・情報共有を安全に運用することを目的とし、外部API直接呼び出しや大容量ファイル送信などに制約があるため、プロキシ設計・ファイル分割/変換・中継基盤を前提にした実装が求められる。

── 行政領域特有の制約や前例の少ない技術領域に取り組む中で、スピード感と将来設計を少数精鋭で両立しようとしているのが印象的ですが、その基盤になっているものは何なのでしょうか？

大橋さん：
3つあると考えています。

まず1つ目は「新しい技術をまず試してみる」文化です。
パブテクでは、気になる技術があればまず触って検証し、その結果をすぐに実装や設計に反映していくことを大事にしています。こうしたトライアンドエラーのサイクルを早く回すことで、技術選定の幅も自然と広がり、開発プロセス全体のスピード感につながっています。

2つ目は、スピードと安全性を両立するために工夫した、“パブテク流”のトランクベース開発です。
品質を落とさず、素早く現場の課題に応えるため、トランクベース開発をベースにしながら、tRPCとFeature Flagを組み合わせて運用を最適化しています。

この仕組みによって、まずは小さくリリースしながらも、ユーザー環境に影響を出すことなく新機能を段階的に展開できるようになりました。確実性が求められる場面でも、スピードを保ったまま安全に検証を進められるのが、大きなメリットです。

▼開発プロセスの工夫については、テックブログでも紹介しています
『tRPC x Feature Flag で実現するスムーズなトランクベース開発』

https://zenn.dev/pubtech/articles/trpc-feature-flag-trunkbase

最後の3つ目は、「将来を見据えた設計を徹底する」という共通認識です。
パブテクには技術負債を極力つくらない思想が根付いており、日々の実装でも“短期のスピードと長期の拡張性”のバランスを常に意識しています。
少人数だからこそ密なコミュニケーションが取れ、「他プロダクトに影響しないか？」「将来の拡張性を妨げない設計か？」といった視点を共有しながら、主体的に提案し実装していけるのも強みです。

新しい技術を素早く取り入れる柔軟さ、スピードを捨てずに安全に開発できる技術的な工夫、そして主体的に動ける少数精鋭の体制。

この“スピード・安全性・将来性”を同時に満たす文化と仕組みが組み合わさることで、行政領域のように前例の少ないフィールドでも、前に進みながら、長期的に破綻しない設計を実現できていると感じています。

生成AIが「土台」を作る。その分、人間は「本質」に集中する。ポストAI時代の開発とは。

── 先ほど「新しい技術を積極的に取り入れている」というお話がありましたが、その中でも生成AIの活用は開発にどんな影響を与えていますか？

大橋さん：
生成AIの活用については、もはや一般的になってきていると思っています。汎用的な部分を生成AIに任せて、エンジニアはより本質的な判断に集中する──その前提はすでに共通認識ですよね。

パブテクでも同様で、再現性の高いタスクは生成AIが非同期的に進めてくれる仕組みを整えています。AI対応IDEやコードエージェント（Cursor/Windsurf/Claude Code等）を、初期案作成からレビュー、CLI補助までケースに応じて併用。Issue作成時にサブタスクを自動生成したり、DevinにJr.エンジニアレベルの処理を任せたりすることで、開発の下準備が自動的に進むようにしています。

一方で、正解のないチャレンジングな領域は、エンジニアが生成AIと同期的に開発を進めていきます。行政仕様に合わせて最適な設計を探ったり、実際に触って検証したりと、人の判断が必要な部分にはしっかり向き合って進めています。

こうした生成AIが非同期的に進める部分と、エンジニアが同期的に進める部分が同時並行で動く構造が、スピードのある開発につながっています。汎用的な部分は生成AIが先に進めてくれることで、人が向き合うべきチャレンジングな領域に集中できる。このバランスは、少数精鋭で開発を進めるうえでも非常に大きいと感じています。

── 生成AIの進化によって、開発や設計の向き合い方は変わりましたか？

大橋さん：
先ほども触れた通り、汎用的な部分はまず生成AIに任せる──そんな進め方がすっかり当たり前になりました。結果として、僕自身もコードを書く量は以前より確実に減り、レビューや動作確認、ドメインモデルや概念設計など、人の理解と判断が欠かせない部分により時間を使えるようになっています。

組織としても、開発体制に良い変化が生まれています。

パブテクでは、追加機能の仕様や設計の初期案を、まず生成AIと対話しながらドキュメントとして整理するプロセスを取り入れています。ある程度形が見えてきた段階でエンジニアにレビューを依頼することで、関わるメンバーは新しい仕様の意図を早い段階で理解できますし、そのまま新メンバーのオンボーディング資料としても機能します。

さらに、判断の背景や検討プロセスがそのままドキュメントに蓄積されていくため、チーム全体の学習速度が上がり、知識の属人化も防げる。生成AIの活用が、結果としてチームの成長基盤を強化する仕組みとしても機能していると感じます。

── 一方で、生成AIを活用しつつも、「人が担うべき領域」はどこにあると考えていますか？

大橋さん：
明確に「人が担うべき領域」として意識しているのは、設計と検証です。

生成AIを活用はしますが、「生成AIを使うこと」が目的化してしまうのは本末転倒です。人が本質的に判断すべき部分に、より集中できるように生成AIを使うという考え方がベースにあります。

生成AIは大きな助けになりますが、どれだけ活用が進んでも、構造をどう作るか、仕様をどう定義するか、そして正しく動くかを確かめることは、人間が判断すべき部分だと考えています。

特に行政領域は、自治体職員の方の業務フローや文脈を深く理解したうえで設計していく必要があります。ここは人間が丁寧に考え、検証していくべきところです。

構造や仕様をどうするかは人が深く考える、汎用的な機能実装は生成AIの力を借りる。その役割分担を明確にすることで、スピードと品質の両立をしていきたいですね。

── 生成AIを巡るトレンドは日々進化していますが、その盛り上がりをどのように捉えていますか？

そもそも生成AIは、既存の実装や業務のボトムラインを押し上げる技術であって、まだ専門領域のトップラインを引き上げる技術ではありません。

AIを使うことが目的化してしまって、何を解決するために使うのかという議論が置き去りになっているケースも多いですよね。ある種「バブル的な盛り上がり」だと感じることもあります。

行政領域で言えば、そもそも生成AIを使いこなす準備がまだ整っていなかったりします。なので、「自治体職員の方が本当に困っているところに生成AIをどう正しく当てていくか」という点に向き合わないと、サービスとしてただのコスト負けになるだけです。そうならないように、「何のために、どう使うか」は考え続ける必要があると思っています。

行政の“当たり前”を自分たちでつくる。パブテク技術開発部の次なる挑戦。

── 今後の開発で、どのような領域に挑んでいきたいと考えていますか？

大橋さん：
「パブテクAI行政」には、まだまだ広げられる領域がたくさんあると感じています。いまはパソコンに付きっきりじゃないと進められない機能が多いですが、将来的にはパソコンから離れた本質的な行政業務に集中していただき、庶務はちょっとした指示から生成AIが裏側で自動で進めておく──そんな世界観を実現したいと思っています。

そして、この領域に本気で踏み込めるのは、パブテクならではの強みがあるからだと感じています。パブテクは自治体領域に特化して開発してきたことで、業務文脈や制度理解まで含めた“ドメイン知識”が蓄積されてきました。だからこそ、汎用的な生成AIや広範な市場を対象とする大手企業では参入しづらい、行政の実務に密着した高度な自動化にも挑戦できると考えています。

また、エンジニアが増えたら、「一人一機能」レベルでプロジェクトを並行開発できる体制を実現したいです。単に機能を増やすだけでなく、プロダクトの安定性向上、バグ削減、チケッティング整備など、組織としての開発基盤を強くすることにも力を入れていきたいと考えています。

── パブテク全体としても組織が大きくなっているフェーズで、エンジニアも新しい仲間を募集していますが、どんなエンジニアがフィットすると思いますか？

大橋さん：
一言でいえば、「動かしながら考えられる、チャレンジングな人」とぜひ一緒に開発したいです。

パブテクでは複数のプロダクトや機能が同時並行で進みますし、行政向けAIソリューションという前例の多くない領域に挑戦しています。だからこそ、手を動かしながら仮説を立て、素早く形にし、実際に現場で役立っているかどうかを検証するというサイクルがとても重要になります。

そこで欠かせないのは、自律性です。

生成AIがあるからこそ、自分の考えを持ったうえで「このプロダクトにはこれが必要だ」と判断し、主体的に動いていける人。そういうエンジニアがフィットすると思いますし、楽しんでいけるはず。

逆に、ドキュメントが揃っていないと動けないタイプの方は難しいかもしれません（笑）。スタートアップなので、何もない状態から最適解を組み立てていく楽しさを感じられるかどうかが大切です。

── 最後に、この記事を読んでパブテクに興味を持ってくれた方へ、メッセージをお願いします。

行政の現場には、本来あって当たり前のはずなのに、まだ仕組みが存在していない領域がたくさんあります。そこに向けて、僕たちは短期的に作って終わりではなく、長い時間軸の中でプロダクトを育て続けてきましたし、これからも育て続けていきます。

スピード・安全性・将来設計のバランスを取りながら、開発、リリース、改善を高速に回していく。

その中で、これまで存在しなかった“当たり前”をプロダクトとして形にし、さらに良い当たり前へと磨き続けていく。

そうやって、僕たちの掲げる「Japanese Dynamism―地域から世界へ、日本を躍動させる」というビジョンに向けて、技術の力で社会の土台をつくり変えていくことに、少しでもワクワクしてもらえたなら、きっとこの挑戦を一緒に楽しめるはずです。

この国の“当たり前”をアップデートしていく仲間が増えることを、心から楽しみにしています。