同じtsconfigでもESMが読み込めないエラーがでたりでなかったり

目的

本記事ではNode.jsとTypeScriptを業務で利用しているエンジニア向けに、同じスクリプトでも実行環境によって動いたり動かなかったりする原因を調査した内容を共有します。

導入

シェルパ・アンド・カンパニー株式会社でプロダクト開発を担当しているkokiです。

このあいだ次のような不思議な現象が報告されました。

1. もともと以下のコマンドを、各開発者がローカルで必要になったタイミングで実行していた。
   • npx ts-node ./test.ts
2. ある日、1.のコマンドを実行するとエラーが出て実行できなくなっていた
   • エラーメッセージ(一部): Error [ERR_REQUIRE_ESM]: require() of ES Module
3. 該当箇所周辺をコミットしていた人はenv-cmd -f ./.env.local npx ts-node ./test.tsというスクリプトで実行していた。この実行は成功する
   1. 補足: env-cmd は環境変数を読み込んでコマンドを実行するツールです。環境変数は本筋とは関係ありませんでした。

最初は「ESMとCommonJSの違いについてtsconfigを見てけば良さそう」と思ってたのですがこの予想は外れ、なぜ env-cmd 経由だと動くのか、すぐには原因を突き止められませんでした。(※1)

結論

MUI DataGridPremiumでcolumnとfilterModelのfield型を連携させて型安全にする

シェルパ・アンド・カンパニー株式会社でプロダクト開発を担当しているペトロフです。開発中に抱えていた課題を踏まえ、Tipsを公開します。

補足

• 使用するTypeScriptのVersionは5.8.3
• 使用する@mui/x-data-grid-premiumのVersionは^6.18.1
  • MUI Grid Data Doc
• 使用するIDEはVScode

やりたいこと

以下のソースではcolumnsとfilterModelではfieldをstring型で自由に設定できます。しかし、columnsとfilterModelのfield値が合わなければ、フィルタ機能は正常に動作しません。そもそもstring型で自由に文字列を設定できることに違和感がありました。

DoclingにGoogle Cloud Visionを組み込み高精度に日本語資料を解析する

はじめに

AI事業部でソフトウェアエンジニアをしている神田（@kampersanda）です。

本記事では、文書解析ツールDoclingのOCRプラグイン機能を使用し、日本語資料を解析する方法を紹介します。本記事は、高精度な日本語PDF資料の解析を目的とし、日本語資料の解析に興味があるソフトウェアエンジニアに向けて記述されます。

自然言語処理の重要な要素技術の一つに、PDF資料の解析が存在します。多くの情報はPDFとして表現されており、そのフォーマットや内容も多種多様です。これらPDFの情報を有効活用するためには、書かれている内容を解析し、システムが扱いやすい形式に変換する処理が重要となります。

本記事では、上記の変換処理を文書解析と呼び、以下のように定義します。

PDFや画像で表現された文書データを、MarkdownやJSONなどの構造化された形式に変換する処理

この文書解析を実現するソフトウェアの一つに、IBM Researchによって開発されているDoclingがあります。

github.com

Amplify gen2 × Prisma を利用した開発基盤

エンジニアの上野 伸一です。フルスタックエンジニアで、クラウド・ネイティブな構成を積極的に採用しています。

要求分析・設計時にはアリスター・コーバーンのユースケースをベースとし、データドリブンなアプローチを好んでおり、TH-Model、TM（T字形ER）などをプロジェクトに応じて適用度を検討する、データモデリングから開発がチョットデキル人です。

Amplify gen2 × Prismaを利用した開発基盤

私がはじめてAmplifyを利用したのは、前職時代のgen 1、CLIがver 3（4, 5年前）でした。何も指定がなければ、Azureを採用（PaaS寄り）する事が多いのですが、AWSという指定があったのでAmplifyでもやってみるかと思い採用しました。

・・・が、エンタープライズで利用するのは早計だったと感じました。当時のAmplifyはリリースして日が浅いという事もあり、致命的なIssueの数が膨大で開発コストの7割近くをAmplify固有の環境Issueに費やす事になりました。

当時の公式GitHub Issueの中には、『解決できない問題が発生したら、一度すべて削除して環境を作り直せ』という、銀の弾丸的な解決方法が紹介されており、なかなかのインパクトでした。（gen1であれば、今でもたまにやるのが悲しいところ）

　 gen2では、IaC周りの刷新とSandboxによる独立した開発者用環境が利用できる点に魅力を感じ、これなら五月雨での開発において、開発者体験を下げずにうまく運用が回るかもしれないと感じました。

実際に弊社で適用し、十二分に使えると感じたので、ちょっとしたソリューション例を交えて紹介します。

ストレージ・データモデリングについて考える

エンジニアの上野 伸一です。フルスタックエンジニアで、クラウド・ネイティブな構成を積極的に採用しています。

要求分析・設計時にはアリスター・コーバーンのユースケースをベースとし、データドリブンなアプローチを好んでおり、TH-Model、TM（T字形ER）などをプロジェクトに応じて適用度を検討する、データモデリングから開発がチョットデキル人です。

なお、本記事の内容は個人としての見解であり、所属する組織とは関係がありません。

Key-Value ストレージの利用

ここではエンタープライズ・システムで利用するというコンテキストに絞ってお話します。

弊社ではAWSのDynamoDBをストレージの1つとして利用しています。

NLP2025参加記

はじめに

シェルパ・アンド・カンパニー株式会社の梶川（AI事業部インターン）と神田（AI事業部）です。

弊社ではESG領域の課題解決を中心的テーマとして自然言語処理技術の研究開発を行っています。去る2025年3月に開催された言語処理学会第31回年次大会（NLP2025）ではプラチナスポンサーとして協賛・出展し、また1件の学会発表を行いました。本記事では、その参加の様子や発表内容を報告します。

NLP2025のセクションは神田が、それ以降のセクションは梶川が執筆を担当します。

SmarESGプロダクト開発のこれまでとこれから

序文

みなさん、こんにちは。シェルパ・アンド・カンパニーVPoEの小川です。

本記事は2024年のアドベントカレンダーの内容を一部改変し、弊社の技術ブログの最初の投稿としています。 これから技術的な投稿を継続にしていきたいと思っておりますがまずは弊社の現在の状態の説明という形で本記事を投稿しています。 どうぞよろしくお願い致します。

現在のラインナップ

大変ありがたいことに昨年も多くのお客様にSmartESGをご導入頂きました。

ビジネスの成長と共にプロダクトとしてのラインナップも順調に増えており組織・製品としてのフェーズも刻一刻と変化してきていると肌身で感じています。