Webサイトのお助け隊

「Webサイトのフォームから送られた内容を、社内のグループウェアに自動で登録したい」。転記の手間をなくしたいという、はっきりした要望です。転記そのものを止めるのは難しくありません。実際に止まるのは、そこではない場所です。契約している製品にAPIがあるのか、外部のサーバーからそのAPIを叩ける設定になっているのか、どのユーザーの権限で登録するのか。この3つを先に潰しておかないと、コードは書けているのに一度も通らない、という状態で時間だけが過ぎます。

作るものは3か所しかない

構成としては、フォームを受けるPHP、送る内容を整えて検証する処理、グループウェアのAPIへ投げる処理の3つです。ここに、失敗したときに記録して後から再送する仕組みを足すかどうかで、費用が変わります。転記が1日に数件で、失敗したら人が気づける規模なら再送の仕組みは要りません。1日に数十件が流れ、担当者が結果を見ていないなら必須です。

意外と見落とされるのが、フォーム側の置き場所です。フォームの action から呼ぶPHPは、サーバー上の独立したファイルとして置き、そこへ送信する形にします。CMSの固定ページ本文にPHPのコードを貼り付けても実行されません。これは非エンジニアの担当者がほぼ必ず一度やることなので、最初に図で説明しておくとやり取りが1往復減ります。

もう一つ。自動返信メールや登録内容のテンプレートは、PHPのコードの中に書かないでください。mail.txt のような別のテキストファイルに切り出しておくと、文面を直したいときに担当者自身がFTPでその1ファイルを開けば済みます。以前この形で納品したところ、その後の案件でも同じ構成をそのまま使うことになりました。文面の修正で毎回発注が必要な作りは、運用が始まるとすぐに嫌われます。

着手前に確認する4点

グループウェア連携の見積りが出せない、あるいは出しても外れるのは、たいていこの4点が未確認のまま進んでいるからです。

認証について補足します。クラウド版のサイボウズ製品は、サブドメインが付いたURLでログインする形になっており、APIを叩くときもその点は同じです。ログイン名とパスワードをコロンでつないでBase64にした値を X-Cybozu-Authorization ヘッダへ載せる方式が基本形で、製品によってはAPIトークンを発行して使えます。パスワード方式にすると、担当者のパスワード変更で連携が止まります。トークンが使える製品なら、そちらを選んでください。

4つ目のアクセス制限は、実務でいちばん多い足止めです。社外からの利用を絞るためにIPアドレス制限をかけていたり、クライアント証明書を使うセキュアアクセスを有効にしていたりすると、Webサーバーから投げたリクエストは認証以前の段階で弾かれます。連携用のサーバーのIPアドレスを許可してもらう手続きが必要になり、これは情報システム部門の判断が入るため、開発より時間がかかることがあります。着手日ではなく、見積りの時点で確認してください。認証まわりで詰まる箇所は製品を問わず似ているので、OAuth連携でつまずくのは、たいてい同じ3か所に絞られるも合わせて見ておくと予測が立てやすくなります。

権限は「連携専用のユーザー」で切る

APIで登録したデータが誰の名前で入るか、そしてどこまで見えるかは、実行するユーザーの権限で決まります。ここで管理者アカウントを流用すると、フォームからの登録処理が社内の全データにアクセスできる状態になります。連携専用のユーザーを1つ作り、必要な範囲だけ権限を与えてください。ライセンスがユーザー数で課金される契約なら、1名分の追加が発生することもあるので、費用の話として先に出しておきます。

鍵そのものの置き場所も決めておいてください。ソースコードに直接書く、リポジトリに入れる、共有フォルダのテキストに置く、のいずれもよくある事故の入口です。APIキーはどこに置き、誰が管理するのかのほうに、置き場所の選び方をまとめています。

法人の案件で個人情報を扱う場合、こちらから先に誓約書を用意して提出するようにしています。相手方の情報システム部門にとっては、外部の人間にテナントのアカウントを発行することそのものが判断の対象です。書面が先に出ていると、この判断が一気に進みます。実際にこの手順で、アカウント発行までの往復が大幅に短くなった案件があります。

実際にあった案件：本番テナントの上でJavaScriptを足す

クラウド版のメールワイズで、送信前に入力内容をチェックしたいという依頼を受けたことがあります。担当者が返信メールを作る際に、宛名や選択項目の記入漏れ・書き間違いを送信前に止めたい、という要望でした。画面側のカスタマイズなので、JavaScriptで実装しています。ここで踏んだ落とし穴が、そのままグループウェア連携の注意点になります。

まず、カスタマイズ用のJavaScriptは1ファイルしか登録できません。既に別のJSが登録されている場合、それを取り込んで1本にマージする必要があります。関数名が衝突すると既存の動作が壊れるため、着手前に既存ファイルの有無を必ず確認してください。

次に、画面上の項目に振られているIDは契約テナントごとに異なります。自分の検証用環境で作ったコードは、そのままでは相手のテナントで動きません。実装にはそのテナントのテストユーザーが必ず要る、という前提を見積りの段階で織り込んでおく必要があります。そして本番テナントでの作業は、業務停止のリスクに直結します。「現在あるメールには一切手を付けない」といった指示を厳守し、テストユーザーの権限の範囲内だけで動かします。

検証ロジックそのものにも、細かい罠がいくつもありました。選択肢の妥当性を部分一致で判定すると、期待していない文字列が通ります。特定の支払方法を表す語を含む任意の文字列がすべて通過してしまい、完全一致か、前後の境界まで含めた判定に直しています。氏名の欄は敬称の「様」があらかじめ入っていることが多く、単純な空欄チェックでは素通りしました。敬称を除いた残りで判定する形にしています。そして、すべてのメールに検証がかかると業務が止まります。件名などで対象メールを限定する条件を、最初に入れておいてください。

この案件では「入力内容の誤字を自動で検出したい」という要望もありましたが、これは照合の基準がない限り原理的に不可能です。代わりに、項目名に番号を割り当てて番号と文字列を突き合わせる、という運用ルール側の提案に切り替えました。自動化の相談では、技術で解けない部分を早めに名指しして、運用の側で解く形に振り替えるほうが早く着地します。

環境が変わると、連携は無言で止まります

自社サーバーに設置したパッケージ版で起きた話です。サイトのSSL化作業の後、グループウェアが開けなくなったという緊急の相談でした。原因は証明書でもhttpsへの切り替えでもなく、ドキュメントルートの変更です。公開ディレクトリが切り替わったことで、サブディレクトリに置かれていたCGIのグループウェアが公開領域の外に出ていました。この型は繰り返し起きるので、「いまのドキュメントルートはどこか」「対象のディレクトリはその配下にあるか」を最初に確認します。

復旧では、アプリケーションを動かしませんでした。新しいサブドメインを旧ドキュメントルートに向けてアクセスを回復させ、旧URLからは301リダイレクトで誘導する形です。ファイル移動もデータベースの移行も伴わないため障害リスクが小さく、夜間の緊急対応に向きます。ここで一つ危なかったのが、ディレクトリを丸ごとコピーしようとした場面です。cb7 配下に実行用のシェルスクリプトが置かれていることに気づき、コピーを中止しました。実行パスが固定されたスクリプトがある状態でディレクトリを二重化すると、二重実行やデータ不整合を起こします。連携やバッチが動いている環境をコピーする前には、cronと常駐スクリプトの有無を必ず確認してください。

もう一点、パッケージ版のグループウェアは管理画面からしか設定を確認できず、FTPで中を見ても全容が追えません。参照しているCSSが別のディレクトリにあった、ということも起きます。この種の製品を扱うときは、「ここまでは責任を持って対応できる、ここから先は提供元の領域」という線を先に引いて伝えるようにしています。なお、承認待ちで有効化できない設定は、.htaccess に記述したうえで # でコメントアウトして納品します。有効化と無効化の手順を文章で添えておけば、先方の都合のよいタイミングで安全に切り替えられ、作業の証跡も残ります。

よくある質問

Garoonのワークフローに、外部から申請を起票できますか

製品のバージョンと契約プラン、そして使えるAPIの種類によって変わります。同じ「Garoon」でも、クラウド版とパッケージ版、さらにバージョンによって外部から操作できる範囲が違うため、まず提供元のAPIドキュメントで対象の操作が公開されているかを確認するところから始めてください。ここが確定しないうちに実装の見積りを出すのは無理があります。

クラウド版とパッケージ版、どちらが連携しやすいですか

APIが用意されている範囲ではクラウド版のほうが素直です。パッケージ版はサーバーの中に置かれている分、ドキュメントルートの変更やサーバー移行のたびに影響を受けます。一方で、社内ネットワークの中で完結させたい要件にはパッケージ版が向きます。連携のしやすさだけで決められる話ではありません。

テスト環境は用意したほうがよいですか

画面側のカスタマイズを伴うなら、テナントを分けたテスト環境よりも、本番テナントの中にテストユーザーを作るほうが確実です。項目のIDがテナントごとに違うため、別テナントで作ったものはそのままでは動きません。ただし本番での作業になるので、触ってよい範囲を書面で確定させてから着手してください。

他のクラウドサービスと同じ作り方でよいですか

考え方は同じです。認証、権限、失敗時の扱いの3点が設計の中心になります。ZohoとWordPressの問い合わせフォームを連携して自動登録するのほうで、重複登録と再送の持ち方を具体的に書いているので、そちらの構成がほぼそのまま使えます。